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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, updates, etc. 
z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document provides the protocol details for the Customized Ringing Signal (CRS) service in the IP 
Multimedia (IM) Core Network (CN) subsystem based on the requirements from 3GPP TS 22.183 [2]. 

The CRS service is an operator specific service by which an operator enables the subscriber to customize the media which 
is played to the called party as an incoming communication indication during establishment of a communication 

The present document is applicable to User Equipment (UE) and Application Servers (AS) which are intended to support 
the CRS service. 
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3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in 3GPP TR 21.905 [1] and the following apply. 
A term defined in the present document takes precedence over the definition of the same term, if any, in 
3GPPTR 21.905 [1]. 
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Media component: A media component, described by the SDP, is a separate data-flow related to a media type which is 
sent by using an IP -based transport protocol (e.g. RTF). Multiple media components may be used in the same session to 
send multiple media types. 

3.2 Abbreviations 

For the purposes of the present document, the abbreviations given in 3GPP TR 21.905 [1] and the following apply. An 
abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in 
3GPPTR 21.905 [1]. 

CRS Customized Ringing Signal 



Customized Ringing Signal (CRS) 



4.1 Introduction 

The CRS service is an operator specific service by which an operator enables the subscriber to customize the media which 
is played to the called party during alerting of the called party. The media can consist of music, voice, text, video or other 
customized ringing signals. 

4.2 Description 
4.2.1 General description 

The service user is able to subscribe to the CRS service, activate (or de-activate) the service, and update the settings, e.g., 
to change by configuration the active CRS media. The media can consist of favourable songs, multimedia clips or other 
customized ring signals. The CRS subscriber is able to refine the CRS media selection behaviour with configured rules, 
e.g. time, calling party's location, called party's location, the identity of the calling and called party. The CRS service is 
able to select the appropriate CRS media according to the rules. 

CRS is an originating network service, but can also have a terminating network functional component. That is, CRS media 
can be selected on behalf of the calling subscriber, but the called (IMS) subscriber can also subscribe to and activate the 
CRS service. Whether or not the called party's CRS media has precedence over the calling party" s selected CRS media is 
a matter of configuration in the called party" s (terminating) network. 

The presentation of the selected CRS media to the called party starts some time following the initiation of a session, but 
prior to session answer. When the called party answers, the CRS media either stops or continues during the conversation, 
depending on operator or user preferences. 

4.3 Operational requirements 
4.3.1 Provision/withdrawal 

4.3.1.1 CRS provision/withdrawal 

The CRS service may be provided after prior arrangement with the service provider. 

The CRS service may be withdrawn at the subscriber"s request or for administrative reasons. 

4.3.1 .2 Requirements on the originating network side 

The originating network side may support the "early-session" extension as described in RFC 3959 [7]. For the early 
session model, if the CRS service is provided by the originating network, the CRS AS shall control an MRF as described 
in 3GPP TS 24.229 [3] that is acting on behalf of a calling subscriber who has activated CRS. 
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The CRS service implementing the download and play model adds no additional requirements on the originating network 
side. 

4.3.1 .3 Requirements on the terminating network side 

The terminating network side may support the "early-session" extension as described in RFC 3959 [7]. 

NOTE: the CRS service implementing the early-session model needs the early-session extension to be supported by 
intermediate entities and the terminating UE, else CRS media can not be provided to the called party. 

The CRS service implementing the download and play model adds no additional requirements on the terminating network 
side. 

For early session model, if the CRS service is provided by the terminating network, the CRS AS shall control an MRF as 
described in 3GPP TS 24.229 [3] that is acting on behalf of a called subscriber who has activated CRS. 

4.4 Syntax requirements 

There are no new protocol requirements for the CRS service. 

4.5 Signalling procedures 

4.5.1 General 

Configuration of supplementary services by the user should: 

take place over the Ut interface using XCAP as enabling protocol as described in 3GPP TS 24.623 [5]; or 

use SIP based user configuration as described in 3GPP TS 24.238 [6]. 

NOTE: Other possibilities for user configuration, such as web-based provisioning or pre-provisioning by the 
operator are outside the scope of the present document, but are not precluded. 

The details of the XCAP document of CRS service are not specified in this version of the document. 

4.5.2 Activatlon/deactlvatlon 

The CRS service is activated at provisioning and deactivated at withdrawal. 

When a CRS service is activated a subscriber can specify which CRS a called user should experience, or use the operator's 
default setting. 

After a subscriber has activated his CRS service a called user experiences the CRS that was chosen by the subscriber, or if 
the called user has activated his CRS service, he can experiences the CRS that was chosen by himself. 

When a CRS service is deactivated a subscriber will not send any CRS to a called user. 

After a subscriber has deactivated his CRS service a called user will not experience any CRS unless the called user has 
actived his CRS service and revert to any alerting provided by the UE. 

4.5.3 Registration/erasure 

The CRS service requires no registration. Erasure is not applicable. 

4.5.4 Interrogation 

For CRS, interrogation is not applicable. 
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4.5.5 Invocation and operation 

4.5.5.1 Actions at the originating UE 

The UE shall follow the procedures specified in 3GPP TS 24.229 [3] for session initiation and termination. 

If a specific CRS media that the originating UE wants to play to the terminating UE, the originating UE shall insert an 
Alert-Info header field with a URL which indicate the specific CRS media defined by the CRS AS that serving the 
originating UE, and a XML body as specified in annex D need to add in the initial SIP INVITE request and delivered to 
the CRS AS that serving the originating UE for further instruction. 

4.5.5.2 Actions at the terminating UE 

4.5.5.2.1 General 

The UE shall follow the procedures specified in 3GPP TS 24.229 [3] for session termination. 

If the terminating UE supports the early session mechanism then the UE shall make use of the procedures as specified in 
RFC 3959 [4]. 

Upon receiving the CRS media, the terminating UE shall play the CRS media. If media type of the local ringing signal is 
not in conflict with media type of the received CRS media, the local ringing signal shall be played at the same time to the 
received CRS media otherwise the local ringing signal shall not be played. 

NOTE: how to decide that the media type of the local ringing signal is conflict with the media type of the CRS 
media type depends on UE implemention. 

4.5.5.2.2 UE Actions for download and play model 

4.5.5.2.2.1 General 

If the terminating UE supports the download and play model, and an initial INVITE request contains an Alert-Info header 
field including an URI followed by a URN "urn:alert:service:crs", then the UE shall fetch and play the CRS media from 
the URL contained in Alert-Info header field in the INVITE request from the CRS AS. 

4.5.5.2.2.2 UE Actions for CRS copy 

In order for the called party to copy the media for the CRS service, the UE shall send a specific DTMF digit for CRS copy. 

NOTE: The definition of which DTMFs are used is outside the scope of this specification and is dependant on the 
implementation of operator. 

4.5.5.2.2.3 UE Actions for CRS stop 

It is the local action of UE for the called party to stop and restart the media of the CRS service. 



4.5.5.2.3 UE Actions for early session model 

4.5.5.2.3.1 General 

The UE shall follow the procedures specified in 3GPP TS 24.229 [3] for session termination with following additions: 

Upon receiving an initial INVITE request, the UE shall: 

check whether an Alert-Info header field with an URN "urn:alert:service:crs" present; 

If present, then: 

- send a reliable SIP 18x response as specified in 3GPP TS 24.229 [3]; 
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do not play local ringing tone to terminating user when a 180 response is sent; 

if SIP PRACK request containing an SDP early session offer, containing an SDP a=content attribute with a 
"a.3gpp.crs" value for each media description is received, send back a SIP 200 response to the request 
including an SDP early session answer; 

receive the CRS media from network and play it as ringing tone. 

NOTE: The UE shall play local ringing tone if no CRS media is received within a specific time. 

4.5.5.2.3.2 UE Actions for CRS copy 

In order for the called party to copy the media for the CRS service, the UE shall send a specific DTMF digit for CRS copy. 

NOTE: The definition of which DTMFs are used is outside the scope of this specification and is dependant on the 
implementation of operator. 

4.5.5.2.4 UE support of DTMF 

In addition to indicating support of the telephone-event media subtype in the SDP answer, as defined in 
3GPP TS 24.229 [3], the UE shall indicate support the SIP INFO mechanism for DTMF transport, as defined in 
3GPP TS 24.229 [3], by including a Recv-Info header field with a "infoDtmf value, as defined in IETF RFC 6086 [7]. 
The AS will indicate to the UE which DTMF transport mechanism to use for CRS control. 

4.5.5.2.3.2 UE Actions for CRS stop 

In order for the called party to stop the media for the CRS service, the UE shall send a specific DTMF digit for CRS stop. 

In order for the called party to restart the media for the CRS service, the UE shall send a specific DTMF digit for CRS 
restart. 

NOTE: The definition of which DTMFs are used is outside the scope of this specification and is dependant on the 
implementation of operator. 

4.5.5.3 Actions at the AS serving the originating UE 

4.5.5.3.1 General 

The procedures specified in 3GPP TS 24.229 [3] for an AS acting as a routing B2BUA apply with additions described in 
the subclauses below. 

Upon receiving a SIP INVITE request contains a XML body as specified in annex D, the AS shall fetch the URL 
indication for a specific CRS media in the Alter-Info header field as indicated in annex D, and delete this URL indication 
in the Alert-Info header field and delete the XML body before forwarding the SIP INVITE request. 

If the first reliable SIP 18x response destined to served user includes a Require header field with "early-session" 
option-tag and the AS supports the "early-session" extension as described in RFC 3959 [4], the AS shall based on operator 
policy follow the procedures in subclause 4.5.5.3.2 to provide CRS service according to the configuration rules, e.g. time, 
calling party's location, called party's location, the identity of the calling and called party, if privacy is required, any 
information which should be private can not be used as the rules to provide the CRS service. The procedures in 
subclause 4.5.5.3.2 shall not be used if there are intermediates in the network that do not support the early session 
extention. In addition, intermediates and network policy must allow media towards the terminating UE before the call has 
been answered. 

4.5.5.3.2 AS Actions for early session model 

4.5.5.3.2.1 General AS actions 

Upon receiving an initial INVITE request from the served user, the AS shall forward the initial INVITE request to the 
terminating UE after inserting an Alert-Info header field with an URN "urn:alert:service:crs". 
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Upon receiving the first reliable SIP 18x response to the initial INVITE request including a Supported header field with 
"early-session" tag, as described in RFC 3959 [4], the AS: 

may contact the MRF to request CRS resource; and 

shall forward the reliable SIP 18x response to the originating UE. 

Upon receiving the PRACK request of the first reliable SIP 18x response from the served user, the AS shall: 

1) contact the MRF to request CRS resource if it has not been previously requested; and 

2) forward the SIP PRACK request to the terminating UE. The PRACK request shall: 

include a P-Asserted-Identity header field containing the public user identity of the served user; and 

include the SDP content for CRS as early-session SDP offer based on the information from the MRF and if 
preconditions are used, indicate the local preconditions are fulfilled. The early session SDP offer shall contain 
an SDP a=content attribute with a "g.3gpp.crs" value for each media description. 

Upon receiving a SIP 200 (OK) response to the SIP PRACK request of the first reliable SIP 18x response, the AS shall 
remove the early-session SDP answer in the SIP 200 (OK) response, and forward the response to the originator of the SIP 
PRACK request. 

Upon receiving additional SIP 18x responses to the initial INVITE request, the AS shall forward them to the originating 
UE. 

Upon receiving a SIP UPDATE request from served user, the AS shall: 

generate an early-session SDP offer based on the information from the MRF and, if preconditions are used, 
indicate that the local preconditions are fulfilled; 

include the early-session SDP offer in the SIP request, and forward it to the terminating UE; and 

after receiving a SIP 200 (OK) response to the request, remove the early-session SDP answer in the SIP 200 (OK) 
response, and forwards the response to the originator. 

NOTE 1 : The early-session SDP offer included in the SIP UPDATE request can in some cases be identical to a 

previous early-session SDP offer sent towards the terminating UE, if the associated media parameters have 
not changed. 

If preconditions are used, the AS should not instruct the MRF to start applicable media for the CRS service before the both 
the originating and terminating UE have indicated that local preconditions are fulfilled, and a 180 (Ringing) response has 
been received from the terminating UE. 

If a SIP message from served UE containing an SDP offer related to an early session is received, the AS shall send an SDP 
answer to the SDP offer related to the early-session sent by the served UE and set all port numbers of the media types to 
"0". 

Upon receiving a SIP 200 (OK) response from the terminating UE to the initial INVITE request, the AS shall instruct the 
MRF to stop media for the CRS service and forward the SIP 200 (OK) response to the originating UE. 

NOTE 2: The interaction between the AS and MRF is not specified for the CRS service but can use the Cr reference 
point as described in 3GPP TS 24.229 [3]. 

Upon receiving a SIP 4xx, 5xx or 6xx response from the terminating UE the AS shall: 

instruct the MRF to stop the media for the CRS service; and 

forward the final response to the originating UE. 

4.5.5.3.2.2 AS Actions for CRS stop 

Upon receipt of the specific DTMF digit for CRS stop, the AS instructs the MRF to stop the media for the CRS service. 

Upon receipt of the specific DTMF digit for CRS restart, the AS instructs the MRF to restart the media for the CRS 
service. 
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4.5.5.3.2.3 AS Actions for CRS continue 

Upon receiving the SIP 200 (OK) response of the SIP INVITE request from terminating UE, the AS shall: 

a) decide whether the CRS media need to be stopped or continuously played based on the operator policy and the 
calling subscribers' preferences; 

b) if the CRS media is provided by the originating network, and the calling party need the CRS media to be 
continuously played, then: 

1) send a SIP ACK to terminating UE; 

2) contact the MRF to request resource of CRS media and original session; 

3) send a SIP re-INVITE request to terminating UE. The SIP re-INVITE request shall include a SDP offer composed 
of both the original session media received in the last SDP offer plus the CRS media components apart from those 
used in the original session based on the information from MRF, and include an SDP a=content attribute with a 
"g.3gpp.crs" value for each media description associated with CRS media. 

4) if a SIP 200 (OK) response containing a SDP answer of the re-INVITE request from the terminating network is 
received, the AS shall: 

send a SIP UPDATE request to originating UE. The SIP UPDATE request shall include a SDP offer related to 
the media of original session and the IP address and port is set based on the information from MRF. 

upon receiving a SIP 200 (OK) response of SIP UPDATE request from originating UE, send a SIP 200 (OK) 
response of the SIP INVITE request to originating UE. 

upon receiving the SIP ACK from originating UE, instruct MRF to start to mix CRS media and regular media 
for terminating UE and just forward regular media to originating UE. 

otherwise if a SIP 488 (Not Acceptable Here) response of the SIP re-INVITE request from the terminating network is 
received, the AS shall send a SIP 200 (OK) response of the SIP INVITE request to the originating UE, but don"t need to 
instruct MRF to start to mix CRS media and regular media for terminating UE. 

4.5.5.3.3 AS Actions for download and play model 

Upon receiving an initial INVITE request from the served user, the AS supporting download and play model shall insert 
an Alert-Info header field with the URI of the CRS media labeled with the URN "urn:alert:service:crs" as the value into 
the INVITE request, and forward the INVITE request to the terminating UE. 

4.5.5.3.4 AS Actions for CRS copy 

Upon receipt of the specific DTMF digit, the AS copies the media for the calling party's CRS service. 
NOTE: How the AS copies the calling party's CRS is out of the scope of this document. 

4.5.5.3.5 AS support of DTMF 

If the UE has indicated support of both the "telephone-event" media subtype and the SIP INFO mechanism for DTMF 
transport, the AS shall based on operator policy choose which DTMF transport mechanism to use for CRS control 
between the UE and the AS. 

If the AS wants to use the SIP INFO mechanism for DTMF transport, as defined in 3GPP TS 24.229 [3], the AS shall 
indicate support of the mechanism in the initial SIP INVITE request sent towards the terminating UE by including a 
Recv-Info header field with a "infoDtmf" value, as defined in IETF RFC 6086 [7]. 

If the AS wants to use the "telephone-event" media subtype for DTMF transport, the AS shall include the 
"telephone-event" in the SDP for CRS media, sent to the UE. 

NOTE: The usage of the "telephone-event" media subtype for CRS control requires that intermediates allow the 
telephone-event packages to traverse from the UE to the AS during the early dialog. 
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For the remainder of this subclause, when the term "receipt of DTMF digit" is used, it means either the detection of a 
DTMF digit by the MRF, which is then passed to the AS over the Cr interface, or the receipt of an INFO request 
containing the appropriate INFO package, as negotiated above. 

4.5.5.4 Actions at the AS serving the terminating UE 

4.5.5.4.1 AS Actions for CRS stop 

When using early session model, upon receipt of the specific DTMF digit for CRS stop, the AS instructs the MRF to stop 
the media for the CRS service. 

When using early session model, upon receipt of the specific DTMF digit for CRS restart, the AS instructs the MRF to 
restart the media for the CRS service. 

4.5.5.4.2 AS Actions for early session model 

4.5.5.4.2.1 General 

The procedures in subclause 4.5.5.3.2 shall apply with following additions: 

Upon receiving the initial INVITE request containing an Alert-Info header field including only an URN 
"urn:alert:service:crs", the AS shall: 

decide which CRS service should have priority based on the operator policy and the called CRS service 
subscriber's preferences; 

if the CRS service provided by the AS serving the terminating UE has no priority, then forward the initial 
INVITE request and do not provide CRS service; 

if the CRS service provided by the AS serving the terminating UE has priority, then upon receiving the PRACK 
request of the first reliable 18x response to the initial INVITE request: 

a) send the PRACK request to the terminating UE. The request shall include the SDP content for CRS service 
provided by the AS serving the terminating UE instead of the CRS service provided by the AS serving the 
originating UE as early-session SDP offer and if preconditions are used, and CRS resource has been 
requested, indicate the local preconditions are fulfilled; 

b) if a 200 (OK) response of PRACK request from terminating UE containing an SDP answer related to an 
early session is received, the AS shall forward the 200 (OK) response with a new SDP answer related to the 
early-session and set all port numbers of the media types to "0". 

Upon receiving the initial INVITE request including the Alert-Info header field with both an URL of CRS media 
and an URN "urn:alert:service:crs", the AS shall: 

decide which CRS service should have priority based on the operator policy and the called CRS service 
subscriber" s preferences; 

if the CRS service provided by the AS serving the terminating UE has no priority, then forward the INVITE 
request and do not provide CRS service; 

if the CRS service provided by the AS serving the terminating UE has priority, then: 

a) forward the INVITE request after removing the Alert-Info header field; and 

b) send a PRACK request to the terminating UE upon receiving the PRACK request from the originating 
network of the first reliable SIP 18x response. The PRACK request shall include the SDP content for CRS 
as early-session SDP offer and if preconditions are used, and CRS resource has been requested, indicate the 
local preconditions are fulfilled. 

if a 200 (OK) response of PRACK request from terminating UE containing an SDP answer related to an early 
session is received, the AS shall forward the 200 response after removing the SDP answer related to the early 
session. 
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4.5.5.4.2.2 AS Actions for CRS continue 

Upon receiving the SIP 200 (OK) response of the SIP INVITE request from terminating UE, the AS shall: 

a) decide whether the CRS media need to be stopped or continuously played based on the operator policy and the 
called subscribers" preferences; 

b) if the CRS media is provided by the terminating network, and the called party needs the CRS media to be 
continuously played, then: 

1) send a SIP ACK to terminating UE; 

2) contact the MRF to request resource of CRS media and original session; 

3) send a SIP re-INVITE request to terminating UE. The SIP re-INVITE request shall include a SDP offer 
composed of both the original session media received in the last SDP offer plus the CRS media components 
apart from those used in the original session based on the information from MRF, and include an SDP 
a=content attribute with a "g.3gpp.crs" value for each media description associated with CRS media.. 

4)upon receiving a SIP 200 (OK) response contain a SDP answer of the SIP re-INVITE request from the 

terminating UE, send a SIP UPDATE request to originating UE. The UPDATE request shall include a SDP 
offer related to the media of original session and the IP address and port is set based on the information from 
MRF. 

5) upon receiving a SIP 200 (OK) response of the SIP UPDATE request from originating UE, send a SIP 200 
(OK) of the SIP INVITE request to the originating UE. 

6) upon receiving the SIP ACK from originating UE, instruct MRF to start to mix CRS media and regular media 
for terminating UE and just forward regular media to originating UE. 

c) if the CRS media is provided by the originating network, and the calling party need the CRS media to be 
continuously played while the called party does not need the CRS media to be continuously played, then: 

1) upon receiving the first SIP re-INVITE request after forwarding the final SIP 200 (OK) response send from the 
terminating UE, the AS shall: 

check whether an SDP a=content attribute with a "g.3gpp.crs" value is present for some media components. 

If present, then: 

Send a SIP 488 (Not Acceptable Here) response to reject the SIP re-INVITE request. 

4.5.5.4.2.3 AS action of CRS Reject 

This subclause describes the procedures when the CRS AS has decided to reject CRS offered by the AS serving the 
originating UE. 

Upon receiving the initial INVITE request containing an Alert-Info header field including an URN "urn:alert:service:crs", 
the AS shall decide whether the CRS service provided by the AS serving the originating UE should be rejected based on 
the operator policy and the called CRS service subscriber's preferences. 

NOTE: Based on the operator policy, the AS can decide whether to reject the originating CRS service when 
receiving the first SIP INVITE request or receiving the PRACK request. 

If the CRS service provided by the AS serving the originating UE needs to be rejected, the AS shall: 

remove the Alert-Info header field; 

when receiving the PRACK request of the first reliable 18x response to the initial INVITE request, 

remove the early-session SDP content for CRS service provided by the AS serving the originating UE; 

forward the PRACK request to the terminating UE; and 
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if a 200 (OK) response of the PRACK request from terminating UE is received, the AS shall forward the 200 
(OK) response with a new SDP answer related to the early-session and set all port numbers of the media types 
to "0". 

Upon receiving the initial INVITE request including the Alert-Info header field with a URL of CRS media, the AS shall 
decide whether the CRS service provided by the AS serving the originating UE should be rejected based on the operator 
policy and the called CRS service subscriber"s preferences. If the CRS service provided by the AS serving the originating 
UE needs to be rejected, the AS shall forward the INVITE request after removing the Alert-Info header field. 

4.5.5.4.3 AS support of DTMF 

If the UE has indicated support of both the "telephone-event" media subtype and the SIP INFO mechanism for DTMF 
transport, the AS shall based on operator policy choose which DTMF transport mechanism to use for CRS control 
between the UE and the AS. 

If the AS wants to use the SIP INFO mechanism for DTMF transport, as defined in 3GPP TS 24.229 [3], the AS shall 
indicate support of the mechanism in the initial SIP INVITE request sent towards the terminating UE by including a 
Recv-Info header field with a "infoDtmf" value, as defined in IETF RFC 6086 [7]. 

If the AS wants to use the "telephone-event" media subtype for DTMF transport, the AS shall include the 
"telephone-event" in the SDP for CRS media, sent to the UE. 

NOTE: The usage of the "telephone-event" media subtype for CRS control requires that intermediates allow the 
telephone-event packages to traverse from the UE to the AS during the early dialog. 

For the remainder of this subclause, when the term "receipt of DTMF digit" is used, it means either the detection of a 
DTMF digit by the MRF, which is then passed to the AS over the Cr interface, or the receipt of an INFO request 
containing the appropriate INFO package, as negotiated above. 

4.5.5.4.4 AS Actions for download and play model 

The procedures in subclause 4.5.5.3.3 shall apply with following additions: 

Upon receiving the initial INVITE request including an Alert-Info header field containing both an URL of CRS 
media and an URN "urn:alert:service:crs", the AS shall: 

decide which CRS service has priority, based on the operator policy and the called CRS service subscriber"s 
preferences; and 

if the CRS service provided by the AS serving the terminating UE has no priority, then forward the INVITE 
request and do not provide CRS service; or 

if the CRS service provided by the AS serving the terminating UE has priority, then replace the URL in the 
Alert-Info header with the URL of CRS media specified by terminating user. 

4.6 Interaction with other services 

4.6.1 Communication session Hold (HOLD) 

In the case that CRS service is stopped after the communication is answered, there is no impact between CRS service and 
HOLD. 

In the case that CRS service is continued after the communication is answered, whether the CRS will also be hold or not 
by the CRS AS when user requests HOLD depends on user's preferences and capability of terminating UE. 

4.6.2 Termination Identification Presentation (TIP) 

No impact, i.e. neither service shall affect the operation of the other service. 
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4.6.3 Termination Identification Restriction (TIR) 

No impact, i.e. neither service shall affect the operation of the other service. 

4.6.4 Originating Identification presentation (OIP) 

No impact, i.e. neither service shall affect the operation of the other service. 

4.6.5 Originating Identification Restriction (OIR) 

The OIR service takes precedence over the CRS service. If the OIR service prevents CRS media from being played to the 
called party, then the AS providing CRS service shall not apply the CRS service to the session. 

4.6.6 Conference (CONF) 

No impact, i.e. neither service shall affect the operation of the other service. 

4.6.7 Communication Diversion (CDIV) 

4.6.7.1 General 

If the calling party has CRS service and diverting party has both CRS service and CDIV active, when the diverted-to party 
does not have active CRS service, based on operator policy, either: 

a) the CRS service of the calling party shall be applied to the session by the AS providing the CRS service of calling 
party; or 

b) the CRS service of the diverting party shall be applied to the session by the AS providing CRS service for the 
diverting party. 

If the calling party has CRS service and diverting party has both CRS service and CDIV active, when the diverted-to party 
also not has active CRS service, based on operator policy, either: 

a) the CRS service of the calling party shall be applied to the session by the AS providing the CRS service of calling 
party; or 

b) the CRS service of the diverting party shall be applied to the session by the AS providing CRS service for the 
diverting party; or 

c) the CRS service of the divert-to party shall be applied to the session by the AS providing CRS service for the 
divert-to party. 

4.6.7.2 CFNR 

Based on operator policy, Tthe CRS service of the calling party shall be applied to the session by the AS providing CRS 
service for the calling party until the CFNR timer expires. Alternatively, the CRS service of the diverting party shall be 
applied to the session by the AS providing CRS service for the diverting party until the CFNR timer expires. 

Upon the CFNR timer expiring, based on operator policy, either: 

a) the CRS service of the calling party shall be applied to the session by the AS providing the CRS service of calling 
party; or 

b) the CRS service of the diverting party shall be applied to the session by the AS providing CRS service for the 
diverting party; or 

c) the CRS service of the divert-to party shall be applied to the session by the AS providing CRS service for the 
divert-to party. 
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4.6.8 Message Waiting Indication (MWI) 

No impact, i.e. neither service shall affect the operation of the other service. 

4.6.9 Communication Barring (CB) 

No impact, i.e. neither service shall affect the operation of the other service. 

4.6.10 Communication Waiting (CW) 

The Communication Waiting alert, or the CRS service of calling party or called party whose audio information is replaced 
by the communication waiting indication shall be applied, based on operator policy. 

If the calling party has CRS service, and the called party does not have active CRS service, based on operator policy, 
either: 

a) the Communication Waiting alert shall be applied by the MMTEL AS; or 

b) the CRS service of calling party shall be applied by the AS providing the CRS service of calling party. 
If the calling party and the called party both have active CRS service, based on operator policy, either: 

a) the Communication Waiting alert shall be applied by the MMTEL AS; 

b) the CRS service of calling party shall be applied by the AS providing the CRS service of calling party; or 

c) the CRS service of called party whose audio information is replaced by the communication waiting indication shall 
be applied by the AS providing the CRS service of called party. 

4.6.1 1 Explicit Communication Transfer (ECT) 

Before the call is transferring, the CRS service of calling party shall be applied by the AS providing the CRS service of 
calling party depending on operator setting,, otherwise the CRS service of transferor shall be applied by the AS providing 
the CRS service of transferor. 

Upon the ECT service is invoked, depending on operator setting., either: 

a) the CRS service of calling party shall be applied by the AS providing the CRS service of calling party; 

b) the CRS service of transferor shall be applied by the AS providing the CRS service of transferor; or 

c) the CRS service of transfer target shall be applied by the AS providing the CRS service of transfer target. 

4.6.12 Completion of Communications to Busy Subscriber (CCBS) 

No impact, i.e. neither service shall affect the operation of the other service. 

4.7 Service configuration 

User configuration of CRS service may use Ut interface, SIP based user configuration as described in 
3GPP TS 24.238 [6] or other possible interfaces. 

The details of the Ut interface are not specified in this version of the document. 
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Annex A (informative): 
Signalling flows 



User configuration of CRS service may use Ut interface, SIP based user configuration as described in 
3GPP TS 24.238 [6] or other possible interfaces. 

The details of the Ut interface are not specified in this version of the document. 



A.1 CRS down and play model signalling flows 
A. 1.1 Introduction 

The following flows show establishment of a session between UE#1 and UE#2, using the down and play model described 
in subclause 4.5.5.3.2 to provide CRS to UE#2. The following flows are included: 

subclause A. 1.2 shows CRS, using the down and play model, when UE#1 and UE#2 have resources available. 
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A.1 .2 CRS when UE#1 and UE#2 have resources available 



UE#1 



Resources available 



— 1. INVITE (SDP_0) 



9. 180 



13. 200 OK 
(SDP_A) 



14. ACK 



S-CSCF 



2. INVITE (SDP_0) 



3. INVITE (SDP_0) 
(Alert-Info) 

4. INVITE (SDP_0) 
(Alert-Info) 



■5. 180 
■6. 180 



■8. 180 



10. 200(SDP_A) 



11.200(SDP_A) 

_ 12. 200 OK 
(SDP_A) 



15. ACK 

16. ACK 

17. ACK 



CRS-AS 



UE#2 



Resources available 



7. fetch CRS content, 
Start CRS content 



Called party answers 
the call 



Stop CRS content 



Figure A.1.2-1 : CRS, UE#1 and UE#2 have resource available 

1 INVITE request (UE#1 to CRS-AS) see example in table A.1.2-1 

UE#1 sends a SIP INVITE request to the intermediate IM CN subsystem. 
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Table A.I. 2-1 : INVITE request (UE#1 to S-CSCF) 



INVITE tel:+l-212-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Max-Forwards: 70 

Route : <sip :pcscf 1 . visitedl .net : 7531; lr;comp=sigcomp>, <sip:scscfl .homel .net ; lr> 

P-Pref erred-Identity : "John Doe" <sip :userl_publicl@homel .net> 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

P- Preferred- Service : urn: urn- 7 : 3gpp- service . ims . icsi .mmtel 

Accept -Contact : * ; +g. 3gpp . icsi_ref="urn%3Aurn-7%3gpp- service . ims .icsi .mmtel" 

Privacy: none 

P-Early-Media : supported 

From: <sip :userl_publicl@homel .net>; tag=17182 8 

To: <tel:+l-212-555-2222> 

Call -ID: Cb03a0s09a2sdfglkj 490333 

Cseq: 127 INVITE 

Require: sec -agree 

Supported: precondition, lOOrel, gruu, 199 

Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c=98765432 ; spi-s=87654321; 

port-c=8642; port-s=7531 
Contact: <sip: 

userl_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-0 0a0c91e6bf 6>; +g. 3gpp . icsi-r 

ef="urn%3Aurn-7%3gpp- service . ims . icsi .mmtel" 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Accept : application/sdp, application/3gpp-ims+xml 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=video 34 RTP/AVP 98 

a=tcap:l RTP/AVPF 

a=pcfg:l t=l 

b=AS:75 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

m=audio 3456 RTP/AVP 97 96 

a=tcap:l RTP/AVPF 

a=pcfg:l t=l 

b=AS:25 .4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; maxframes=2 

a=rtpmap:96 telephone-event 



Supported: The UE indicates support for GRUU, 199 responses, reliable provisional responses and preconditions. 

SDP The SDP offer (SDP_0) contains a set of codecs supported by UE#1 and desired by the calling user for this session. 
The local preconditions are indicated as fulfilled. 

2 INVITE request (S-CSCF to CRS-AS) 

The S-CSCF forwards the SIP INVITE request to the CRS-AS. 

3-4 INVITE request (CRS-AS to UE#2) see example in table A.1.2-3 

The CRS-AS add an Alert-Info header field with the address of CRS media as the value into the SIP INVITE 
request, and forwards the SIP INVITE request to UE#2. 
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Table A.1.2-3: INVITE request (CRS-AS to S-CSCF) 



INVITE tel:+l-212-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Max-Forwards: 70 

Route : <sip :pcscf 1 . visitedl .net : 7531; lr;comp=sigcomp>, <sip:scscfl .homel .net ; lr> 

P-Pref erred-Identity : "John Doe" <sip :userl_publicl@homel .net> 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

P- Preferred- Service : urn: urn- 7 : 3gpp- service . ims . icsi .mmtel 

Accept -Contact : * ; +g. 3gpp . icsi_ref="urn%3Aurn-7%3gpp- service . ims .icsi .mmtel" 

Privacy: none 

P-Early-Media : supported 

From: <sip :userl_publicl@homel .net>; tag=17182 8 

To: <tel:+l-212-555-2222> 

Call -ID: Cb03a0s09a2sdfglkj 490333 

Cseq: 127 INVITE 

Require: sec-agree 

Recv-Info: infoDtmf 

Supported: precondition, lOOrel, gruu, 199 

Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c=98765432 ; spi-s=87654321; 

port-c=8642; port-s=7531 
Contact: <sip: 

userl_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lldO-a765-OOaOc91e6bf 6>; +g. 3gpp . icsi-r 

ef="urn%3Aurn-7%3gpp- service . ims . icsi .mmtel" 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Accept : application/sdp, application/3gpp-ims+xml 
Content-Type: application/sdp 
Content-Length: (...) 
Alert -Info: <http: //aaa .bbb . ccc .ddd/cid/600/300/0/0000/0000/002 .mov>;purpose=icon 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa :bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=video 34 RTP/AVP 98 

a=tcap:l RTP/AVPF 

a=pcfg:l t=l 

b=AS:75 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

m=audio 3456 RTP/AVP 97 96 

a=tcap:l RTP/AVPF 

a=pcfg:l t=l 

b=AS:25 .4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; maxframes=2 

a=rtpmap:96 telephone -event 



Alert-Info: The Alert-Info header field contains the address of the CRS media. 

5-6 180 (Ringing) provisional response (UE#2 to CRS-AS) 

The called party is alerted. UE#2 sends a SIP 180 (Ringing) provisional response for the INVITE request to the 
CRS-AS. 

7 fetch and play CRS media 

The called party fetches the CRS media from the address carried in the Alert-Info header field, and renders the 
media. 

8-9 180 (Ringing) provisional response (CRS-AS to UE#1) 

The CRS-AS forwards the 180 (Ringing) response to the calling party. 
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10-11 200 (OK) response to INVITE request (UE#2 to CRS-AS) see example in table A.1.2-10 

The called party answers the call. UE#2 stops the playback of CRS media and sends a SIP 200 (OK) final response 
for the SIP INVITE request to the CRS-AS. 

Table A.1.2-10: 200 (OK) response (UE#2 to CRS-AS) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf2 .visited2 .net :5088;comp=sigcomp;branch=z9hG4bK361k21.1, SIP/2. 0/UDP 

scscf 2 .home2 .net ;branch=z9hG4bK764XC12 .1, SIP/2 . 0/UDP 

catas.home2 .net ;branch=z9hG4bK764Q3 2 .1, SIP/2 .0/UDP 

scscf 2 .home2 .net ;branch=z9hG4bK764z87 . 1 , SIP/2 .0/UDP 

icscf2_s.home2 .net ;branch=z9hG4bK8 71yl2 .1, SIP/2 .0/UDP 

scscfl.homel.net;branch=z9hG4bK3 3 2b2 3 .1, SIP/2 .0/UDP 

pcscf 1 .visitedl .net;branch=z9hG4bK240f 34 .1, SIP/2 . 0/UDP 
[5555 : :aaa:bbb: ccc : ddd] : 13 5 7 ; comp=sigcomp;branch=z9hG4bKnashds7 
Record- Route : <sip ipcscf 2 . visited2 .net : 5 088 ; lr;comp=sigcomp>, <sip:scscf2 .home2 .net; lr>, 

<sip:catas .home2 .net;lr>, <sip:scscf2 .home2 .net;lr>, <sip:scscfl .homel .net ; lr>, 

<sip : pcscf 1 .visitedl .net ; lr> 
From: 

To: <tel: +1-212 -555 -2222 >;tag=2236 
Call-ID: 
Cseq: 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Contact : 

< sip: user 2_publicl(ahome2 .net ;gr=urn:uuid: 2ad8 95 0e-4 8a5-4a74-8d9 9-ad7 6cc7f c74>; +g. 3gpp. ic 

si-ref ="urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel" 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 29879336157 29879336157 IN IP6 6666 : : eee : f f f : aaa : bbb 

s = - 

c = IN IP6 6666 : :eee:fff :aaa:bbb 

t=0 

m=video 7398 RTP/AVPF 98 

b=AS:75 

a=curr:qos local sendrecv 

a=curr:qos remote sendrecv 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

m=audio 8386 RTP/AVPF 97 96 

b=AS:2 5.4 

a=curr:qos local sendrecv 

a=curr:qos remote sendrecv 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; maxframes 

a=rtpmap:96 telephone-event 



SDP The SDP answer (SDP_A) contains a set of codecs to be used for the session. If preconditions are used, they are 
indicated as fulfilled. 

12-13 200 (OK) response (CRS-AS to UE#1) 

The CRS-AS forwards the 200 OK final response to the calling party. 
14-15 ACK request (UE#1 to CRS-AS) 

UE#1 sends a SIP ACK request, which acknowledges the SIP 200 (OK) final response, to CRS-AS. 
16-17 ACK request (CRS-AS to UE#2) 

CRS-AS sends a SIP ACK request, which acknowledges the SIP 200 (OK) final response, to UE#2. 
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A.2 CRS signalling flows using early session model 
A.2.1 Introduction 

The following flows show establishment of a session between UE#1 and UE#2, using the early session model described in 
subclause 2.2 to provide CRS to UE#2. The following flows are included: 

subclause A. 2. 2 shows CRS, using the early session model, when UE#1 and UE#2 have resources available; 

subclause A.2. 3 shows CRS, using the early session model, when UE#1 does not have resources available; and 

subclause A.2. 4 shows CRS, using the early session model, when UE#2 does not have resources available. 

A.2.2 CRS when UE#1 and UE#2 have resources available 



UE#1 



S-CSCF 



Resources available 



1. INVITE (SDP_0) 



8. 180(SDP_A) 

9. PRACK 



16.200 



20.200 ■ 
21.ACK 



CRS-AS 



■ 2. INVITE (SDP_0) 

■ 3. INVITE (SDP^O) 

■ 4. INVITE (SDP_0) 

■5. 180(SDP_A) 
■6. 180(SDP_A) 
■7. 180(SDP_A) — 



10.PRACK ■ 



UE#2 



Resources available 



Reserve resources 



11.PRACK(earlySDP_0) ■ 

12. PRACK(earlySDP_0) 

13. 200 (early SDP_A) — 



14. 200 (early SDP_A) 
15.200 



Start CRS media 
(to UE#2) 



17.200 

■ 18.200 ■ 

■ 19.200 ■ 

■ 22. ACK 



Stop CRS media 



Figure A.2.2-1 : CRS, early session model flow when both UE1 and UE2 have resource available 
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1-2 INVITE request (UE#1 to CRS-AS) see example in table A.2.2-1 

UE#1 sends a SIP INVITE request to the intermediate IM CN subsystem. 
The S-CSCF forwards the SIP INVITE request to the CRS-AS. 

Table A.2.2-1 : INVITE request (UE#1 to S-CSCF) 



INVITE tel:+l-212-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa :bbb : ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Max- Forwards : 70 

Route : <sip ipcscf 1 . visitedl .net : 75 31; lr;comp=sigcomp>, <sip lorigOscscf 1 .homel .net ; lr> 

P-Pref erred-Identity : "John Doe" <sip :userl_publicl@homel .net> 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Privacy: none 

From: <sip :userl_publicl@homel . net> ; tag=171828 

To: <tel:+l-212-555-2222> 

Call -ID: Cb03a0s09a2sdfglkj 490333 

Cseq: 127 INVITE 

Supported: precondition, lOOrel 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c=98765432 ; spi-s=87654321; 

port-c=8642; port-s=7531 
Contact : 

<sip :userl_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lldO-a765-OOaOc91e6bf 6>; +g. 3gpp . i 

csi_ref="urn%3Aurn-7%3gpp- service . ims . icsi .mmtel" 
Accept : application/sdp, application/3gpp-ims+xml 
Content-Type: application/sdp 
Content-Disposition: session 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa :bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:25 .4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2 , 5, 7; maxframes=2 

a = r tpmap : 9 6 t e 1 ephone - event 



Supported: The UE indicates support for preconditions, reliable provisional responses, and early-session SDP. 

SDP: The SDP offer (SDP_0) contains a set of codecs supported by UE#1 and desired by the calling user for this 
session. If preconditions are used, the local preconditions are indicated as fulfilled. 

3-4 INVITE request (CRS-AS to UE#2) see example in table A.2.2-3 

The CRS-AS forwards the SIP INVITE request to UE#2. 
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Table A.2.2-3: INVITE request (CRS-AS to UE#2) 



INVITE tel:+l-212-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Max-Forwards: 68 

Route : <sip :pcscf 1 . visitedl .net : 7531; lr;comp=sigcomp>, <sip :orig®scscf 1 .homel .net ; lr>, 

P-Pref erred-Identity : "John Doe" <sip :userl_publicl@homel .net> 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Privacy: none 

From: 

To: 

Call-ID: 

Cseq: 127 INVITE 

Recv-Info: infoDtmf 

Supported: precondition, lOOrel, early-session 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c=98765432 ; spi-s=87654321; 

port-c=8642; port-s=7531 
Contact : 

<sip :userl_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-0 0a0c91e6bf 6>; +g. 3gpp . i 

csi_ref ="urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel" ; +g. 3gpp . crs 
Accept : application/sdp, application/3gpp-ims+xml 
Content-Type: application/sdp 
Content-Disposition: session 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5, 7; maxframes=2 

a=rtpmap:96 telephone-event 



5-6 180 Ringing response (UE#2 to CRS-AS) see example in table A.2.2-5 

Since the SIP INVITE request contains a feature-tag "g.3gpp.crs", UE#2 will not play a local ringing tone when the 
SIP 180 (Ringing) response is sent. Instead UE#2 will, for a specific time, wait for an SDP offer related to CRS 
early session and, if not received, play a local ringing tone. 
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Table A.2.2-5: 180 (Ringing) response (UE#2 to CRS-AS) 



SIP/2.0 180 OK 

Via: SIP/2. 0/UDP pcscf 2 . visited2 .net ;branch=z9hG4bK361k21 . 1, SIP/2. 0/UDP 

scscf2 .home2 .net ;branch=z9hG4bK7 64XC12 .1, SIP/2 .0/UDP 

crsas.home2 .net ;branch=z9hG4bK764Q3 2 .1, SIP/2 .0/UDP 

scscf2.home2 .net ;branch=z9hG4bK764z87 . 1 , SIP/2 .0/UDP 

scscfl.homel.net;branch=z9hG4bK3 3 2b2 3 .1, SIP/2 .0/UDP 

pcscf 1 . visitedl .net ;branch=z9hG4bK24 0f 34 . 1 , SIP/2 . 0/UDP 

[5555 : :aaa:bbb: ccc :ddd] : 13 5 7 ; comp=sigcomp ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
Cseq: 

Require: lOOrel, precondition, early-session 
Contact : <sip : user2_publicl@home2 .net ;gr=urn:uuid: 2ad8 95 0e-4 8a5-4a74-8d99-ad76cc7f c74 

>; +g. 3gpp. icsi_ref ="urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel" 
Content-Type: application/sdp 
Content-Disposition: session 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : eee : f f f : aaa : bbb 

s = - 

c = IN IP6 6666 : :eee:fff :aaa:bbb 

t=0 

m=audio 3456 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local sendrecv 

a=curr:qos remote sendrecv 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; maxframes=2 

a=rtpmap:96 telephone-event 



SDP The SDP answer (SDP_A) contains a set of codecs to be used for the session. The local preconditions are indicated 
as fulfilled. 

7-8 180 (Ringing) response (CRS-AS to UE#1) 

The CRS-AS forwards the SIP 180 (Ringing) response to UE#1. 
9-10 PRACK request (UE#1 to CRS-AS) 

UE#1 sends PRACK request. 
11-12 PRACK request (CRS-AS to UE#2) see example in table A.2.2-11 

CRS-AS reserves CRS resource, and forwards the PRACK request to UE#2 after a CRS SDP is inserted. 
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Table A.2.2-11 : PRACK request (CRS-AS to UE#2) 



PRACK tel:+l-212-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP crsas.home2 .net;branch=z9hG4bK764Q32 .1, SIP/2. 0/UDP 

From: 

To: 

Call-ID: 

Cseq: 

Require: precondition, lOOrel, early-session 

RSeq: 9022 

Contact : <sip : cat-as .homel .net>; +g. 3gpp . icsi_ref="urn%3Aurn-7%3gpp- service . ims . icsi .mmtel" 

Content-Type: application/sdp 

Content -Disposition: early- session 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : eee : f f f : ccc : ddd 

s = - 

c = IN IP6 6666 : :eee:fff :aaa:bbb 

t = 

m=audio 3456 RTP/AVP 97 

b=AS:2 5.4 

a=curr:qos local sendonlt 

a=curr:qos remote none 

a=des:qos mandatory local sendonly 

a=des:qos mandatory remote recvonly 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; maxframes 



early SDP The early-session SDP offer (early SDP_0) contains a set of codecs supported to be used for CRS. The 
local preconditions are indicated as fulfilled. 

13-14 200 (OK) response (UE#2 to CRS-AS) see example in table A,2,2-13 

UE#2 sends the 200 (OK) response which contains an SDP answer to the PRACK request containing the SDP offer 
to CRS-AS. 

Table A.2.2-13:200 (OK) response (UE#2 to CRS-AS) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 2 . visited2 . net ;branch=z9hG4bK361k21 . 1 , SIP/2. 0/UDP 
scscf 2 .home2 .net ;branch=z9hG4bK764XC12 .1, SIP/2 . 0/UDP 
scscfl .homel .net ;branch=z9hG4bK764z87 . 1 , SIP/2 . 0/UDP 
crsas.homel.net;branch=z9hG4bK764Q3 2 .1, SIP/2 .0/UDP 
scscf l.homel.net;branch=z9hG4bK3 3 2b2 3 .1, SIP/2 .0/UDP 
pcscf 1 .visitedl .net ;branch=z9hG4bK24 0f 34 .1, SIP/2 . 0/UDP 
[5555 : :aaa:bbb: ccc :ddd] : 13 5 7 ; comp=sigcomp ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

Cseq: 128 PRACK 

Contact : 

Content-Type: application/sdp 

Content -Disposition: early- session 

Content-Length: (...) 

v=0 

o=- 2987933616 2987933616 IN IP6 5555 :: eee : fff : aaa :bbb 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=audio 3466 RTP/AVP 97 

b=AS:2 5.4 

a=curr:qos local recvonly 

a=curr:qos remote sendonly 

a=des:qos mandatory local recvonly 

a=des:qos none remote sendonly 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; maxframes 



early SDP The early-session SDP answer (early SDP_A) contains a set of codecs supported by UE#2 to be used for 
CRS. The local preconditions are indicated as fulfilled. 
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15-16 200 (OK) response (CRS-AS to UE#1) 

The CRS-AS forwards the 200 (OK) response, to the PRACK request, from which the SDP answer is deleted. 
The CRS-AS instructs the MRF to send CRS media to UE#2. UE#2 presents the CRS media. 
17-18 200 (OK) response to INVITE request (UE#2 to CRS-AS) 

The called party answers the call. UE#2 sends a SIP 200 (OK) final response to the SIP INVITE request towards 

UE#1. 

The CRS-AS stops CRS media. 
19-20 200 (OK) response to INVITE request (CRS-AS to UE#1) 

The CRS-AS forwards the SIP 200 (OK) response to UE#1. 
A regular session is established between UE#1 and UE#2. 
The early session between UE#2 and the CRS-AS is terminated. 
21-22 ACK request (UE#1 to UE#2) 

UE#1 sends a SIP ACK request, which acknowledges the SIP 200 (OK) final response, to UE#2. 
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A.2.3 CRS when UE#1 does not have required resources available 
while UE#2 has resources available 



UE#1 



1. INVITE (SDP_01) 



S-CSCF 



■8. 183{SDP_A1) 
■ 9. PRACK 



11. PRACK( early 
SDP 01) 



12. PRACK{ early SDP_01) 

- 13. 200 (early SDP_A1) — 

- 14. 200 (early SDP_A1) —i 



16. 200 (OK) ■ 



Resources available 



— 17. UPDATE(SDP_02) 



■ 24. 200{SDP_A2) 



■28. 180 



■ 32. 200 (OK) 

■ 33. ACK 



CRS-AS 



-2. INVITE (SDP_01) 
■3. INVITE (SDP_01) 
■4. INVITE (SDP_01) 
■5. 183(SDP_A1 ) - 
■6. 183{SDP_A1) — 



UE#2 



Resources available 



I Reserve CRS resources 



■7.183(SDP_A1) 



10. PRACK 



15. 200 (OK) 



■ 18. UPDATE(SDP_02) 

19. UPDATE (SDP_02, 
" early SDP_02) 

_ 20. UPDATE (SDP_02, 
early SDP_02) 

_21. 200(SDP_A2, 

early SDP_A2) 

_ 22. 200 (SDP_A2, 

early SDP_A2) 

- 23. 200(SDP_A2) 



■ 25. 180 
■26. 180 



Start CRS media 



■27. 180 



■ 29. 200 (OK) 

■ 30. 200 (OK) ■ 

■31. 200 (OK) ■ 



Stop CRS media 



■ 34. ACK 



Figure A.2.3-1 : CRS, UE#1 does not have resource available 

1 INVITE request (UE#1 to CRS-AS) see example in table A.2.3-1 

UE#1 sends a SIP INVITE request to the intermediate IM CN subsystem. 
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Table A.2.3-1 : INVITE request (UE#1 to S-CSCF) 



INVITE tel:+l-212-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Max-Forwards: 70 

Route : <sip :pcscf 1 . visitedl .net : 7531; lr;comp=sigcomp>, <sip :orig®scscf 1 .homel .net; lr> 

P-Pref erred-Identity : "John Doe" <sip :userl_publicl@homel .net> 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Privacy: none 

From: <sip :userl_publicl@homel .net>; tag=17182 8 

To: <tel:+l-212-555-2222> 

Call -ID: Cb03a0s09a2sdfglkj 490333 

Cseq: 127 INVITE 

Supported: precondition, lOOrel, 199 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c=98765432 ; spi-s=87654321; 

port-c=8642; port-s=7531 
Contact : 

<sip :userl_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lldO-a76 5-OOaOc91e6bf 6>; +g. 3gpp . i 

csi_ref="urn%3Aurn-7%3gpp- service. ims . icsi .mmtel" 
Accept : application/sdp, application/3gpp-ims+xml 
Content-Type: application/sdp 
Content-Disposition: session 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=video 34 RTP/AVP 98 

b=AS:75 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=inactive 

a=rtpmap:98 H263 

m=audio 3456 RTP/AVP 97 96 

b=AS:25 .4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=inactive 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5, 7; maxframes=2 

a=rtpmap:96 telephone-event 



Supported: The UE indicates support for preconditions and reliable provisional responses. 

SDP: The SDP offer (SDP_01) contains a set of codecs supported by UE#1 and desired by the user at UE#1 for this 
session. The SDP contains an indication that the local preconditions are not fulfilled. 

2 INVITE request (S-CSCF to CRS-AS) 

The S-CSCF forwards the SIP INVITE request to the CRS-AS. 
3-4 INVITE request (CRS-AS to UE#2) see example in table A.2.3-3 

The CRS-AS forwards the SIP INVITE request to UE#2. 
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Table A.2.3-3: INVITE request (CRS-AS to UE#2) 



INVITE tel:+l-212-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Max-Forwards: 70 

Route : <sip :pcscf 1 . visitedl .net : 7531; lr;comp=sigcomp>, <sip :orig®scscf 1 .homel .net; lr> 

P-Pref erred-Identity : "John Doe" <sip :userl_publicl@homel .net> 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Privacy: none 

From: <sip :userl_publicl@homel .net>; tag=17182 8 

To: <tel:+l-212-555-2222> 

Call -ID: Cb03a0s09a2sdfglkj 490333 

Cseq: 127 INVITE 

Recv-Info: infoDtmf 

Supported: precondition, lOOrel, 199 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c=98765432 ; spi-s=87654321; 

port-c=8642; port-s=7531 
Contact : 

<sip :userl_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a76 5-00a0c91e6bf 6>; +g. 3gpp . i 

csi_ref ="urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel" ; +g. 3gpp . crs 
Accept : application/sdp, application/3gpp-ims+xml 
Content-Type: application/sdp 
Content-Disposition: session 
Content-Length: (...) 



2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : ddd 



v=0 

o= 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=video 34 RTP/AVP 98 

b=AS:75 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=inactive 

a=rtpmap:98 H263 

m=audio 3456 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=inactive 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; maxframes=2 

a=rtpmap:96 telephone-event 



5-6 183 (Session Progress) provisional response (UE#2 to CRS-AS) see example in table A.2.3-5 

UE#2 sends a SIP 183 (Session Progress) provisional response for the INVITE request to the CRS-AS. 
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Table A.2.3-5: 183 (Session Progress) response (UE#2 to CRS-AS) 



SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP pcscf 2 . visited2 .net ;branch=z9hG4bK361k21 . 1, SIP/2. 0/UDP 

scscf2.home2 .net ;branch=z9hG4bK764XC12 .1, SIP/2 .0/UDP 

scscfl.homel.net;branch=z9hG4bK3 3 2b2 3 .1, SIP/2 .0/UDP 

crsas.homel.net;branch=z9hG4bK7 64Q3 2 .1, SIP/2 .0/UDP 

scscf 1. homel.net ;branch=z 9hG4bK3 3 2b2 3 .1, SIP/2 .0/UDP 

pcscf 1 . visitedl .net ;branch=z9hG4bK24 0f 34 . 1 , SIP/2 . 0/UDP 

[5555 : :aaa:bbb: ccc :ddd] : 13 5 7 ; comp=sigcomp ; branch=z9hG4bKnashds7 
From: 

To: <tel: +1-212 -555 -2222 >;tag=6322 
Call-ID: 
Cseq: 

Require: lOOrel, precondition, early-session, 199 
RSeq: 9021 
Contact : 

< sip: user 2_publicl8home2 .net ;gr=urn:uuid: 2ad8 95 0e-4 8a5-4a74-8d9 9-ad7 6cc7f c74>; +g . 3gpp. ic 

si_ref ="urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel" 
Content-Type: application/sdp 
Content-Disposition: session 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : eee : f f f : aaa : bbb 

s = - 

c = IN IP6 5555 : :eee:fff :aaa:bbb 

t = 

m=video 34 RTP/AVP 98 

b=AS:75 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

m=audio 3456 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5, 7; maxframes=2 

a=rtpmap:96 telephone-event 



SDP: The SDP answer (SDP_A1) contains a set of codecs to be used for the session. The local preconditions are 
indicated as fulfilled. 

7-8 183 (Session Progress) provisional response (CRS-AS to UE#1) 

The CRS-AS forwards the SIP 183 (Session Progress) provisional response to UE#1. 

9-10 PRACK request (UE#1 to CRS-AS) see example in table A.2.3-9 

UE#1 sends a SIP PRACK request to acknowledge the 183 (Session Progress) provisional response, towards 

UE#2. 
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Table A.2.3-9: PRACK request (UE#1 to CRS-AS) 



PRACK sip:user2_publicl@home2 .net ;gr=urn:uuid: 2ad8 95 0e-4 8a5-4a74-8d99-ad76cc7f c74 SIP/2 . 

Via: SIP/2. 0/UDP [5555 : : aaa : bbb : ccc : ddd] : 1357 ; comp = sigcomp;branch=z9hG4bKna234s7 

Max-Forwards: 70 

Route : <sip :pcscf 1 . visitedl .net : 7531; lr;comp=sigcomp>, <sip :orig@scscf 1 .homel .net ; lr> 

P-Pref erred-Identity : "John Doe" <sip :userl_publicl@homel .net> 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Privacy: none 

From: 

To: 

Call-ID: 

Cseq: 128 PRACK 

Contact : 

Content-Length: 



11-12 PRACK request (CRS-AS to UE#2) see example in table A.2.3-11 

CRS-AS forwards the SIP PRACK request with early-session SDP offer for CRS to UE#2. 

Table A.2.3-11 : PRACK request (CRS-AS to UE#2) 



PRACK sip:userl_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6 SIP/2 . 
Via: SIP/2. 0/UDP crsas . home2 . net ;branch=z9hG4bK614Q63 . 1 , SIP/2. 0/UDP 

scscfl. homel. net ;branch=z9hG4bK351b51.1, SIP/2 .0/UDP 

pcscfl .visitedl .net;branch=z9hG4bK582f 12 .1, SIP/2 . 0/UDP 

[5555 : : aaa :bbb : ccc :ddd] : 13 57;comp=sigcomp;branch=z9hG4bKjia234s7 
Max- Forwards : 6 6 
Privacy: 
From: 
To: 

Call-ID: 
Cseq: 128 PRACK 
Contact : 

Content-Type: application/sdp 
Content -Disposition: early- session 
Content-Length: (...) 

v=0 

o=- 2987933616 2987933616 IN IP6 5555 :: ccc : aaa : bbb : ace 

s = - 

c = IN IP6 5555 :: ccc : aaa :bbb : ace 

t = 

m=video 34 RTP/AVP 98 

b=AS:75 

a=curr:qos local sendonly 

a=curr:qos remote none 

a=des:qos mandatory local sendonly 

a=des:qos mandatory remote recvonly 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

m=audio 3456 RTP/AVP 97 

b=AS:2 5.4 

a=curr:qos local sendonly 

a=curr:qos remote none 

a=des:qos mandatory local sendonly 

a=des:qos mandatory remote recvonly 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; maxframes 



early SDP: The early-session SDP offer (early SDP_01) contains a set of codecs to be used for CRS. The 
preconditions are indicated as fulfilled. 

13-14 200 (OK) response to PRACK request (UE#2 to CRS-AS) see example in table A.2.3-13 

UE#2 sends a SIP 200 (OK) response for the SIP PRACK request with early-session SDP answer for CRS, towards 
CRS-AS. 
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Table A.2.3-13: 200(OK) response (UE#2 to CRS-AS) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 2 . visited2 .net ;branch=z9hG4bK361k21 . 1, SIP/2. 0/UDP 

scscf2.home2 .net ;branch=z9hG4bK764XC12 .1, SIP/2 .0/UDP 

scscfl.homel.net;branch=z9hG4bK3 3 2b2 3 .1, SIP/2 .0/UDP 

cr£5as.home2 .net ;branch=z9hG4bK7 64Q3 2 .1, SIP/2 .0/UDP 

scscf 1. homel.net ;branch=z 9hG4bK3 3 2b2 3 .1, SIP/2 .0/UDP 

pcscf 1 . visitedl .net ;branch=z9hG4bK24 0f 34 . 1 , SIP/2 . 0/UDP 

[5555 : :aaa:bbb: ccc :ddd] : 13 5 7 ; comp=sigcomp ; branch=z9hG4bKnashds7 
From: 

To: <tel: +1-212 -555 -2222 >;tag=6322 
Call-ID: 
Cseq: 

Require: lOOrel, precondition 
RSeq: 9021 
Contact : 

< sip: user 2_publicl8home2 .net ;gr=urn:uuid: 2ad8 95 0e-4 8a5-4a74-8d9 9-ad7 6cc7f c74>; +g . 3gpp. ic 

si_ref ="urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel" 
Content-Type: application/sdp 
Content -Disposition: early- session 
Content-Length: (...) 

v=0 

o=- 2987933616 2987933616 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=video 3500 RTP/AVP 98 

b=AS:75 

a=curr:qos local recvonly 

a=curr:qos remote sendonly 

a=des:qos mandatory local recvonly 

a=des:qos mandatory remote sendrecv 

a=rtpmap:98 H263 

m=audio 3556 RTP/AVP 97 

b=AS:25 .4 

a=curr:qos local recvonly 

a=curr:qos remote sendonly 

a=des:qos mandatory local recvonly 

a=des:qos mandatory remote sendonly 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; maxframes 



early SDP: The early-session SDP answer (early SDP_A1) contains a set of codecs supported by UE#2 to be used for 
CRS. The preconditions are indicated as fulfilled. 

15-16 200 (OK) response to PRACK request (CRS-AS to UE#1) see example in table A.2.3-15 

CRS-AS forwards the SIP 200(OK) response without early-session SDP answer to UE#1. 

Table A.2.3-15: 200(OK) response (CRS-AS to UE#1) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP crsas.homel.net ;branch=z9hG4bK764Q32 .1, SIP/2. 0/UDP 

scscf 1. homel.net ;branch=z 9hG4bK3 3 2b2 3 .1, SIP/2 .0/UDP 

pcscf 1 .visitedl .net ;branch=z9hG4bK24 0f 34 . 1 , SIP/2 . 0/UDP 

[5555 : : aaa: bbb: ccc :ddd] : 13 5 7 ; comp=sigcomp ; branch=z9hG4bKnashds7 
From: 

To: <tel:+l-212-555-2222>;tag=6322 
Call-ID: 
Cseq: 

Require: lOOrel, precondition, 199 
RSeq: 9021 
Contact : 

< sip: user 2_publicl(ahome2 .net ;gr=urn:uuid: 2ad8 95 0e-4 8a5-4a74-8d99-ad76cc7f c74>; +g. 3gpp. ic 

si_ref ="urn%3Aurn- 7 %3gpp- service . ims .icsi .mmtel" 
Content-Length: 



17-18 UPDATE request (UE#1 to CRS-AS) see example in table A.2.3-17 
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After the resources for regular session is reserved, UE#1 sends a SIP UPDATE request with regular session SDP 
offer towards UE#2. 

Table A.2.3-17: UPDATE request (UE#1 to CRS-AS) 



UPDATE sip:user2_publicl@home2 .net ;gr=urn:uuid: 2ad8 95 0e-4 8a5-4a74-8d99-ad76cc7f c74 SIP/2 . 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKna234s7 

Max- Forwards : 70 

Route : <sip ipcscf 1 . visitedl .net : 7531; lr;comp=sigcomp>, <sip lorigOscscf 1 .homel .net; lr> 

P-Pref erred-Identity : "John Doe" <sip :userl_publicl@homel .net> 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Privacy : none 

From: 

To: 

Call-ID: 

Cseq: 12 9 UPDATE 

Contact : 

Content-Type: application/sdp 

Content-Disposition: session 

v=0 

o=- 2987933615 2987933616 IN IP6 5555 : : aaa : bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=video 34 RTP/AVP 98 

b=AS:75 

a=curr:qos local sendrecv 

a=curr:qos remote sendrecv 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

m=audio 3456 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local sendrecv 

a=curr:qos remote sendrecv 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; maxframes=2 

a = r tpmap :96 telephone- event 



SDP: The SDP offer (SDP_02) contains a set of codecs supported by UE#1 and desired by the user at UE#1 for this 
session. The SDP contains an indication that the preconditions are fulfilled. 

19-20 UPDATE request (CRS-AS to UE#2) see example in table A.2.3-19 

CRS-AS forwards the SIP UPDATE request towards UE#2 with early-session SDP. 
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Table A.2.3-19: UPDATE request (CRS-AS to UE#2) 



UPDATE sip:user2_publicl@home2 .net ;gr=urn:uuid: 2ad8 95 0e-4 8a5-4a74-8d99-ad76cc7f c74 SIP/2 . 
Via: SIP/2. 0/UDP crsas.homel.net;branch=z9hG4bK164Q63 .1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK514b51.1, SIP/2 . 0/UDP 

pcscf 1 .visitedl .net;branch=z9hG4bK812f 12 .1, SIP/2 . 0/UDP 

[5555 : : aaa :bbb: ccc :ddd] : 13 5 7;comp=sigcomp;branch=z9hG4bKna2 34s7 
Max- Forwards : 66 
Privacy: 
From: 
To: 

Call-ID: 

Cseq: 12 9 UPDATE 
Contact : 

Content-Type: multipart/mixed; boundary="boundaryl" 
Content-Length: (...) 

--boundaryl 

Content-Type: application/sdp 

Content-Disposition: session 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=video 34 RTP/AVP 98 

b=AS:75 

a=curr:qos local sendrecv 

a=curr:qos remote sendrecv 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

m=audio 3456 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local sendrecv 

a=curr:qos remote sendrecv 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; maxframes=2 

a=rtpmap:96 telephone-event 

--boundaryl 

Content-Type: application/sdp 

Content -Disposition: early- session 

v=0 

o=- 2987933616 2987933617 IN IP6 5555 :: aaa :bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=video 3500 RTP/AVP 98 

b=AS:75 

a=curr:qos local sendonly 

a=curr:qos remote recvonly 

a=des:qos mandatory local sendonly 

a=des:qos mandatory remote recvonly 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

m=audio 3556 RTP/AVP 97 

b=AS:25 .4 

a=curr:qos local sendonly 

a=curr:qos remote recvonly 

a=des:qos mandatory local sendonly 

a=des:qos mandatory remote recvonly 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; maxframes 

--boundaryl 



early SDP: The early-session SDP offer (early SDP_01) contains a set of codecs to be used for CRS. The local 
preconditions are indicated as fulfilled. 

21-22 200 (OK) response to UPDATE request (UE#2 to CRS-AS) see example in table A.2.3-21 
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UE#2 sends a SIP 200 (OK) response for the SIP UPDATE request to the CRS-AS. 

Table A.2.3-21 : 200 (OK) response (UE#2 to CRS-AS) 



SIP/2 . 
Via: SIP 
scscf 
scscf 
crsas 
scscf 
pcscf 
[5555 
From: 
To: 

Call-ID: 
Cseq: 
Contact : 
Content 
Content 



200 OK 

/2 . 0/UDP pcscf2 .visited2 .net ;branch=z9hG4bK611k21 .1, SIP/2 . 0/UDP 
2 .home2 .net ;branch=z9hG4bK764KS12 .1, SIP/2 . 0/UDP 
l.homel.net;branch=z9hG4bK514b51.1, SIP/2 .0/UDP 

homel.net;branch=z9hG4bK164Q63 .1, SIP/2 .0/UDP 
l.homel.net;branch=z9hG4bK514b51.1, SIP/2 .0/UDP 
l.visitedl.net;branch=z9hG4bK812f 12 .1, SIP/2 .0/UDP 
: : aaa : bbb : ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKna234s7 



Type: multipart/mixed; boundary="boundaryl" 
Length: (...) 



--boundaryl 

Content-Type: application/sdp 

Content-Disposition: session 



v=0 



B7933615 2987933S15 IN IPS 5555 :: eee : fff : aaa :bbb 



c = IN IP6 5555 : :eee:fff :aaa:bbb 

t = 

m=video 34 RTP/AVP 98 

b=AS:75 

a=curr:qos local sendrecv 

a=curr:qos remote sendrecv 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

m=audio 3456 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local sendrecv 

a=curr:qos remote sendrecv 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; maxframes=2 

a=rtpmap:96 telephone-event 

--boundaryl 

Content-Type: application/sdp 

Content -Disposition: early- session 

v=0 

o=- 2987933616 2987933616 IN IP6 5555 :: ccc : aaa :bbb : ace 

s = - 

c=IN IP6 5555 :: ccc : aaa :bbb : ace 

t = 

m=video 34 RTP/AVP 98 

b=AS:75 

a=curr:qos local recvonly 

a=curr:qos remote sendonly 

a=des:qos mandatory local recvonly 

a=des:qos mandatory remote sendonly 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

m=audio 3456 RTP/AVP 97 

b=AS:2 5.4 

a=curr:qos local recvonly 

a=curr:qos remote sendonly 

a=des:qos mandatory local recvonly 

a=des:qos mandatory remote sendonly 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; maxframes 

--boundaryl 
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SDP: The SDP answer (SDP_A2) contains a set of codecs supported by UE#2 to be used for the session. The 
preconditions are indicated as fulfilled. 

early SDP: The early-session SDP answer (early SDP_A2) contains a set of codecs supported by UE#2 to be used for 
CRS. The preconditions are indicated as fulfilled. 

23-24 200 (OK) response to UPDATE request (CRS-AS to UE#1) see example in table A.2.3-23 

CRS -AS forwards the SIP 200 (OK) response to the SIP UPDATE request without early session SDP answer, 
towards UE#1. 

Table A.2.3-23: 200 (OK) response (CRS-AS to UE#1) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP crsas . homel . net ;branch=z9hG4bK164Q63 . 1 , SIP/2. 0/UDP 
scscf 1 .homel .net ;branch=z9hG4bK514b51 . 1 , SIP/2 . 0/UDP 
pcscf 1. visitedl.net ;branch=z9hG4bK812f 12 .1, SIP/2 .0/UDP 
[5555 : :aaa:bbb: ccc : ddd] : 13 5 7 ; comp=sigcomp;branch=z9hG4bKna2 34s7 

From: 

To: 

Call-ID: 

Cseq: 

Contact : 

Content-Type: application/sdp 

Content-Disposition: session 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : eee : f f f : aaa : bbb 

s = - 

c = IN IP6 5555 : :eee:fff :aaa:bbb 

t = 

m=video 34 RTP/AVP 98 

b=AS:75 

a=curr:qos local sendrecv 

a=curr:qos remote sendrecv 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

m=audio 3456 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local sendrecv 

a=curr:qos remote sendrecv 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5, 7; maxframes=2 

a=rtpmap:96 telephone-event 



25-28 180 (Ringing) response to INVITE request (UE#2 to UE#1) 

UE#2 sends a SIP 180 (Ringing) provisional response to the INVITE request towards UE#1. 
The CRS-AS instructs the MRF to play CRS media when it receives the 180 (Ringing) response. 
29-30 200 (OK) response to INVITE request (UE#2 to CRS-AS) 

The called party answers the call. UE#2 sends a SIP 200 (OK) final response to the SIP INVITE request towards 

UE#1. 

The CRS-AS instructs the MRF to stop CRS media. 
31-32 200 (OK) response to INVITE request (CRS-AS to UE#1) 

The CRS-AS forwards the SIP 200 (OK) response to UE#1. 

A regular session is established between UE#1 and UE#2. 

The early session between the CRS-AS and UE#2 is terminated. 
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33-34 ACK request (UE#1 to UE#2) 

UE#1 sends a SIP ACK request, which acknowledges the 200 (OK) final response, to UE#2. 

A.2.4 CRS when UE#1 has required resources available while 
UE#2 do not have resources available 



UE#1 



Resources available 



— 1. INVITE (SDP_01) 



8. 183(SDP_A1) 

9. PRACK 



16. 200 (OK) 



■20. 180 



■ 24. 200 (OK) 

■ 25. ACK 



S-CSCF 



CRS-AS 



■2. INVITE (SDP_01) 
■3. INVITE (SDP_01) 

■4. INVITE (SDP_01) 
■5. 183(SDP_A1) — 
■6. 183(SDP_A1) — 



Reserve CRS resources 



7.183(SDP_A1) 



10. PFRACK 

11. PRACK(early 
SDP_01) 



12. PRACK(earlySDP_01) 

13. 200 (early SDP_A1) — 

14. 200 (early SDP_A1) -» 

15. 200 (OK) 



17. 180 

18. 180 

19. 180 



Start CRS media 



■21. 200 (OK) 
- 22. 200 (OK) ■ 

■ 23. 200 (OK) ■ 



Stop CRS media 



26. ACK 



UE#2 



Resources available 



Figure A.2.4-1 : CRS, UE#2 does not have resource available 
1 INVITE request (UE#1 to CRS-AS) see example in table A.2.4-1 
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UE#1 sends a SIP INVITE request to the intermediate IM CN subsystem. 

Table A.2.4-1 : INVITE request (UE#1 to S-CSCF) 



INVITE tel:+l-212-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Max- Forwards : 7 

Route : <sip :pcscf 1 . visitedl .net : 7531; Ir ; comp=sigcomp> , <sip :orig@scscf 1 .homel .net ; lr> 

P-Pref erred-Identity : "John Doe" <sip :userl_publicl@homel .net> 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Privacy: none 

From: <sip :userl_publicl®homel .net>; tag=17182 8 

To: <tel:+l-212-555-2222> 

Call -ID: Cb03a0s09a2sdfglkj 490333 

Cseq: 127 INVITE 

Supported: precondition, lOOrel, 199 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c=98765432 ; spi-s=87654321; 

port-c=8642; port-s=7531 
Contact : 

<sip :userl_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lldO-a765-OOaOc91e6bf 6>; +g. 3gpp . i 

csi_ref="urn%3Aurn-7%3gpp- service . ims . icsi .mmtel" 
Accept : application/sdp, application/3gpp-ims+xml 
Content-Type: application/sdp 
Content-Disposition: session 
Content-Length: (...) 

v=0 

o = - 2987933615 2987933S15 IN IPS 5555 : : aaa :bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=video 34 RTP/AVP 98 

b=AS:75 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=inactive 

a=rtpmap:98 H263 

m=audio 3456 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=inactive 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2 , 5, 7; maxframes=2 

a = r tpmap :96 telephone- event 



Supported: The UE indicates support for preconditions and reliable provisional responses. 

SDP: The SDP offer (SDP_01) contains a set of codecs supported by UE#1 and desired by the user at UE#1 for this 
session. The SDP contains an indication that the local preconditions are fulfilled. 

2 INVITE request (S-CSCF to CRS-AS) 

The S-CSCF forwards the SIP INVITE request to the CRS-AS. 
3-4 INVITE request (CRS-AS to UE#2) see example in table A.2.4-3 

The CRS-AS forwards the SIP INVITE request to UE#2. 
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Table A.2.4-3: INVITE request (CRS-AS to UE#2) 



INVITE tel:+l-212-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Max-Forwards: 70 

Route : <sip :pcscf 1 . visitedl .net : 7531; lr;comp=sigcomp>, <sip :orig®scscf 1 .homel .net; lr> 

P-Pref erred-Identity : "John Doe" <sip :userl_publicl@homel .net> 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Privacy: none 

From: <sip :userl_publicl@homel .net>; tag=17182 8 

To: <tel:+l-212-555-2222> 

Call -ID: Cb03a0s09a2sdfglkj 490333 

Cseq: 127 INVITE 

Recv-Info: infoDtmf 

Supported: precondition, lOOrel, 199 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c=98765432 ; spi-s=87654321; 

port-c=8642; port-s=7531 
Contact : 

<sip :userl_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a76 5-00a0c91e6bf 6>; +g. 3gpp . i 

csi_ref ="urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel" ; +g. 3gpp . crs 
Accept : application/sdp, application/3gpp-ims+xml 
Content-Type: application/sdp 
Content-Disposition: session 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=video 34 RTP/AVP 98 

b=AS:75 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=inactive 

a=rtpmap:98 H263 

m=audio 3456 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=inactive 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; maxframes=2 

a=rtpmap:96 telephone-event 



5-6 183 (Session Progress) provisional response (UE#2 to CRS-AS) see example in table A.2.4-5 

UE#2 sends a SIP 183 (Session Progress) provisional response for the INVITE request to the CRS-AS. 
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Table A.2.4-5: 183 (Session Progress) response (UE#2 to CRS-AS) 



SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP pcscf 2 . visited2 .net ;branch=z9hG4bK361k21 . 1, SIP/2. 0/UDP 

scscf2.home2 .net ;branch=z9hG4bK764XC12 .1, SIP/2 .0/UDP 

scscfl.homel.net;branch=z9hG4bK3 3 2b2 3 .1, SIP/2 .0/UDP 

crsas.homel.net;branch=z9hG4bK7 64Q3 2 .1, SIP/2 .0/UDP 

scscf 1. homel.net ;branch=z 9hG4bK3 3 2b2 3 .1, SIP/2 .0/UDP 

pcscf 1 . visitedl .net ;branch=z9hG4bK24 0f 34 . 1 , SIP/2 . 0/UDP 

[5555 : :aaa:bbb: ccc :ddd] : 13 5 7 ; comp=sigcomp ; branch=z9hG4bKnashds7 
From: 

To: <tel: +1-212 -555 -2222 >;tag=6322 
Call-ID: 
Cseq: 

Require: lOOrel, precondition, early-session, 199 
RSeq: 9021 
Contact : 

< sip: user 2_publicl8home2 .net ;gr=urn:uuid: 2ad8 95 0e-4 8a5-4a74-8d9 9-ad7 6cc7f c74>; +g . 3gpp. ic 

si_ref ="urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel" 
Content-Type: application/sdp 
Content-Disposition: session 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : eee : f f f : aaa : bbb 

s = - 

c = IN IP6 5555 : :eee:fff :aaa:bbb 

t = 

m=video 34 RTP/AVP 98 

b=AS:75 

a=curr:qos local none 

a=curr:qos remote sendrecv 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

m=audio 3456 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local none 

a=curr:qos remote sendrecv 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5, 7; maxframes=2 

a=rtpmap:96 telephone-event 



SDP: The SDP answer (SDP_A1) contains a set of codecs to be used for the session. The local preconditions are 
indicated as not fulfilled. 

7-8 183 (Session Progress) provisional response (CRS-AS to UE#1) 

The CRS-AS forwards the SIP 183 (Session Progress) provisional response to UE#1. 

9-10 PRACK request (UE#1 to CRS-AS) see example in table A.2.4-9 

UE#1 sends a SIP PRACK request to acknowledge the 183 (Session Progress) provisional response, towards 

UE#2. 
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Table A.2.4-9: PRACK request (UE#1 to CRS-AS) 



PRACK sip:user2_publicl@home2 .net ;gr=urn:uuid: 2ad8 95 0e-4 8a5-4a74-8d99-ad76cc7f c74 SIP/2 . 

Via: SIP/2. 0/UDP [5555 : : aaa : bbb : ccc : ddd] : 1357 ; comp = sigcomp;branch=z9hG4bKna234s7 

Max-Forwards: 70 

Route : <sip :pcscf 1 . visitedl .net : 7531; lr;comp=sigcomp>, <sip :orig@scscf 1 .homel .net ; lr> 

P-Pref erred-Identity : "John Doe" <sip :userl_publicl@homel .net> 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Privacy: none 

From: 

To: 

Call-ID: 

Cseq: 128 PRACK 

Contact : 

Content-Length: 



11-12 PRACK request (CRS-AS to UE#2) see example in table A.2.4-11 

CRS-AS forwards the SIP PRACK request with early-session SDP offer for CRS to UE#2. 

Table A.2.4-11 : PRACK request (CRS-AS to UE#2) 



PRACK sip:userl_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6 SIP/2 . 
Via: SIP/2. 0/UDP crsas . home2 . net ;branch=z9hG4bK614Q63 . 1 , SIP/2. 0/UDP 

scscfl. homel. net ;branch=z9hG4bK351b51.1, SIP/2 .0/UDP 

pcscfl .visitedl .net;branch=z9hG4bK582f 12 .1, SIP/2 . 0/UDP 

[5555 : : aaa :bbb : ccc :ddd] : 13 57;comp=sigcomp;branch=z9hG4bKjia234s7 
Max- Forwards : 6 6 
Privacy: 
From: 
To: 

Call-ID: 
Cseq: 128 PRACK 
Contact : 

Content-Type: application/sdp 
Content -Disposition: early- session 
Content-Length: 

v=0 

o=- 2987933616 2987933616 IN IP6 5555 :: ccc : aaa : bbb : ace 

s = - 

c = IN IP6 5555 :: ccc : aaa :bbb : ace 

t = 

m=video 34 RTP/AVP 98 

b=AS:75 

a=curr:qos local sendonly 

a=curr:qos remote none 

a=des:qos mandatory local sendonly 

a=des:qos mandatory remote recvonly 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

m=audio 3456 RTP/AVP 97 

b=AS:2 5.4 

a=curr:qos local sendonly 

a=curr:qos remote none 

a=des:qos mandatory local sendonly 

a=des:qos mandatory remote recvonly 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; maxframes 



early SDP: The early-session SDP offer (early SDP_01) contains a set of codecs to be used for CRS. The 
preconditions are indicated as fulfilled. 

13-14 200 (OK) response to PRACK request (UE#2 to CRS-AS) see example in table A.2.4-13 

UE#2 sends a SIP 200 (OK) response for the SIP PRACK request with early-session SDP answer for CRS, towards 
CRS-AS. 
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Table A.2.4-13: 200(OK) response (UE#2 to CRS-AS) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 2 . visited2 .net ;branch=z9hG4bK361k21 . 1, SIP/2. 0/UDP 

scscf2.home2 .net ;branch=z9hG4bK764XC12 .1, SIP/2 .0/UDP 

scscfl.homel.net;branch=z9hG4bK3 3 2b2 3 .1, SIP/2 .0/UDP 

cr£5as.home2 .net ;branch=z9hG4bK7 64Q3 2 .1, SIP/2 .0/UDP 

scscf 1. homel.net ;branch=z 9hG4bK3 3 2b2 3 .1, SIP/2 .0/UDP 

pcscf 1 . visitedl .net ;branch=z9hG4bK24 0f 34 . 1 , SIP/2 . 0/UDP 

[5555 : :aaa:bbb: ccc :ddd] : 13 5 7 ; comp=sigcomp ; branch=z9hG4bKnashds7 
From: 

To: <tel: +1-212 -555 -2222 >;tag=6322 
Call-ID: 
Cseq: 

Require: lOOrel, precondition 
RSeq: 9021 
Contact : 

< sip: user 2_publicl8home2 .net ;gr=urn:uuid: 2ad8 95 0e-4 8a5-4a74-8d9 9-ad7 6cc7f c74>; +g . 3gpp. ic 

si_ref ="urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel" 
Content-Type: application/sdp 
Content -Disposition: early- session 
Content-Length: (...) 

v=0 

o=- 2987933616 2987933616 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=video 3500 RTP/AVP 98 

b=AS:75 

a=curr:qos local none 

a=curr:qos remote sendonly 

a=des:qos mandatory local recvonly 

a=des:qos none remote sendonly 

a=rtpmap:98 H263 

m=audio 3556 RTP/AVP 97 

b=AS:25 .4 

a=curr:qos local none 

a=curr:qos remote sendonly 

a=des:qos mandatory local recvonly 

a=des:qos none remote sendonly 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; maxframes 



early SDP: The early-session SDP answer (early SDP_A1) contains a set of codecs supported by UE#2 to be used for 
CRS. The preconditions are indicated as not fulfilled. 

15-16 200 (OK) response to PRACK request (CRS-AS to UE#1) see example in table A.2.4-15 

CRS-AS forwards the SIP 200(OK) response without early-session SDP answer to UE#1. 

Table A.2.4-15: 200(OK) response (CRS-AS to UE#1) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP crsas.homel.net ; branch=z9hG4bK764Q32 .1, SIP/2. 0/UDP 

scscf 1. homel.net ;branch=z 9hG4bK3 3 2b2 3 .1, SIP/2 .0/UDP 

pcscf 1 .visitedl .net ;branch=z9hG4bK24 0f 34 . 1 , SIP/2 . 0/UDP 

[5555 : : aaa: bbb: ccc :ddd] : 13 5 7 ; comp=sigcomp ; branch=z9hG4bKnashds7 
From: 

To: <tel:+l-212-555-2222>;tag=6322 
Call-ID: 
Cseq: 

Require: lOOrel, precondition 
RSeq: 9021 
Contact : 

< sip: user 2_publicl(ahome2 .net ;gr=urn:uuid: 2ad8 95 0e-4 8a5-4a74-8d99-ad76cc7f c74>; +g. 3gpp. ic 

si_ref ="urn%3Aurn- 7 %3gpp- service . ims .icsi .mmtel" 
Content-Length: 



17-20 180 (Ringing) response to INVITE request (UE#2 to UE#1) 

UE#2 sends a SIP 180 (Ringing) provisional response to the INVITE request towards UE#1. 
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The CRS-AS instructs the MRF to play CRS media. 
21-22 200 (OK) response to INVITE request (UE#2 to CRS-AS) 

The called party answers the call. UE#2 sends a SIP 200 (OK) final response to the SIP INVITE request towards 

UE#1. 

The CRS-AS instructs the MRF to stop CRS media. 
23-24 200 (OK) response to INVITE request (CRS-AS to UE#1) 

The CRS-AS forwards the SIP 200 (OK) response to UE#1. 
A regular session is established between UE#1 and UE#2. 
The early session between the CRS-AS and UE#2 is terminated. 
25-26 ACK request (UE#1 to UE#2) 

UE#1 sends a SIP ACK request, which acknowledges the 200 (OK) final response, to UE#2. 
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A.2.5 Continue to play CRS during the conversation 



UE#1 



S-CSCF 



Resources available 



1. INVITE (SDP_01) 



■ 8. 180(SDP_A1) 

■ 9. PRACK 



16.200 



. 26. UPDATE (SDP_03) — 
■ 27. 200 (SDP_A3) 



■ 30. 200 - 
31. ACK 



CRS-AS/MRF 



■2. INVITE (SDP_01) 

■ 3. INVITE (SDP_01) 

■4. INVITE (SDP_01) 

■ 5. 180(SDP_A1) 

■6. 180(SDP_A1) 

■ 7. 180(SDP_A1) — 



10.PRACK ■ 



Reserve resources 



11. PRACK(early SDP_0) 

12. PRACK(early SDP_0) 

13. 200 (early SDP_A) — 

14. 200 (early SDP_A) -»> 
15.200 



Start CRS media 
(to UE#2) 



■ 17.200 ■ 

■ 18.200 ■ 
19. ACK 

■ 20. ACK 



■ 21. re-INVITE (SDP_02) ^ 

■ 22. re-INVITE (SDP_02) - 

- 23. 200 (SDP_A2) 

- 24. 200 (SDP_A2) — 



■ 25. UPDATE (SDP_03) — 



. 28. 200 (SDP_A3) 
— 29. 200 



32. ACK 

33. ACK 



UE#2 



Resources available 



■ 34. ACK 



Mix CRS Media and 
Reaular Media 

Figure A.2.5-1 : continue to play CRS during the conversation 

1-2 INVITE request (UE#1 to CRS-AS) see example in table A.2.5-1 

UE#1 sends a SIP INVITE request to the intermediate IM CN subsystem. 
The S-CSCF forwards the SIP INVITE request to the CRS-AS. 
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Table A.2.5-1 : INVITE request (UE#1 to S-CSCF) 



INVITE tel:+l-212-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Max-Forwards: 70 

Route : <sip :pcscf 1 . visitedl .net : 7531; lr;comp=sigcomp>, <sip :orig®scscf 1 .homel .net; lr> 

P-Pref erred-Identity : "John Doe" <sip :userl_publicl@homel .net> 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Privacy: none 

From: <sip :userl_publicl@homel .net>; tag=17182 8 

To: <tel:+l-212-555-2222> 

Call -ID: Cb03a0s09a2sdfglkj 490333 

Cseq: 127 INVITE 

Supported: precondition, lOOrel 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c=98765432 ; spi-s=87654321; 

port-c=8642; port-s=7531 
Contact : 

<sip :userl_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lldO-a76 5-OOaOc91e6bf 6>; +g. 3gpp . i 

csi_ref="urn%3Aurn-7%3gpp- service. ims . icsi .mmtel" 
Accept : application/sdp, application/3gpp-ims+xml 
Content-Type: application/sdp 
Content-Disposition: session 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:25 .4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; maxframes=2 

a=rtpmap:96 telephone-event 



Supported: The UE indicates support for preconditions, reliable provisional responses, and early-session SDP. 

SDP: The SDP offer (SDP_0) contains a set of codecs supported by UE#1 and desired by the calling user for this 
session. If preconditions are used, the local preconditions are indicated as fulfilled. 

3-4 INVITE request (CRS-AS to UE#2) see example in table A.2.5-3 

The CRS-AS forwards the SIP INVITE request to UE#2. 
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Table A.2.5-3: INVITE request (CRS-AS to UE#2) 



INVITE tel:+l-212-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Max-Forwards: 68 

Route : <sip :pcscf 1 . visitedl .net : 7531; lr;comp=sigcomp>, <sip :orig®scscf 1 .homel .net ; lr>, 

P-Pref erred-Identity : "John Doe" <sip :userl_publicl@homel .net> 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Privacy: none 

From: 

To: 

Call-ID: 

Cseq: 127 INVITE 

Recv-Info: infoDtmf 

Supported: precondition, lOOrel, early-session 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c=98765432 ; spi-s=87654321; 

port-c=8642; port-s=7531 
Contact : 

<sip :userl_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-0 0a0c91e6bf 6>; +g. 3gpp . i 

csi_ref ="urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel" ; +g. 3gpp . crs 
Accept : application/sdp, application/3gpp-ims+xml 
Content-Type: application/sdp 
Content-Disposition: session 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5, 7; maxframes=2 

a=rtpmap:96 telephone-event 



5-6 180 (Ringing) response (UE#2 to CRS-AS) see example in table A.2.5-5 

Since the SIP INVITE request contains a feature-tag "g.3gpp.crs", UE#2 will not play a local ringing tone when the 
SIP 180 (Ringing) response is sent. Instead UE#2 will, for a specific time, wait for an SDP offer related to CRS 
early session and, if not received, play a local ringing tone. 



£75/ 



3GPP TS 24.1 83 version 1 0.0.0 Release 1 49 ETSI TS 1 24 1 83 V1 0.0.0 (201 1 -04) 

Table A.2.5-5: 180 (Ringing) response (UE#2 to CRS-AS) 



SIP/2.0 180 OK 

Via: SIP/2. 0/UDP pcscf 2 . visited2 .net ;branch=z9hG4bK361k21 . 1, SIP/2. 0/UDP 

scscf2 .home2 .net ;branch=z9hG4bK7 64XC12 .1, SIP/2 .0/UDP 

crsas.home2 .net ;branch=z9hG4bK764Q3 2 .1, SIP/2 .0/UDP 

scscf2.home2 .net ;branch=z9hG4bK764z87 . 1 , SIP/2 .0/UDP 

scscfl.homel.net;branch=z9hG4bK3 3 2b2 3 .1, SIP/2 .0/UDP 

pcscf 1 . visitedl .net ;branch=z9hG4bK24 0f 34 . 1 , SIP/2 . 0/UDP 

[5555 : :aaa:bbb: ccc :ddd] : 13 5 7 ; comp=sigcomp ; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
Cseq: 

Require: lOOrel, precondition, early-session 
Contact : <sip : user2_publicl@home2 .net ;gr=urn:uuid: 2ad8 95 0e-4 8a5-4a74-8d99-ad76cc7f c74 

>; +g. 3gpp. icsi_ref ="urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel" 
Content-Type: application/sdp 
Content-Disposition: session 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : eee : f f f : aaa : bbb 

s = - 

c = IN IP6 6666 : :eee:fff :aaa:bbb 

t=0 

m=audio 3456 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local sendrecv 

a=curr:qos remote sendrecv 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; maxframes=2 

a=rtpmap:96 telephone-event 



SDP The SDP answer (SDP_A) contains a set of codecs to be used for the session. The local preconditions are indicated 
as fulfilled. 

7-8 180 (Ringing) response (CRS-AS to UE#1) 

The CRS-AS forwards the SIP 180 (Ringing) response to UE#1. 
9-10 PRACK request (UE#1 to CRS-AS) 

UE#1 sends PRACK request. 
11-12 PRACK request (CRS-AS to UE#2) see example in table A.2.5-11 

CRS-AS reserves CRS resource and forwards the PRACK request to UE#2 after a CRS SDP is inserted. 
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Table A.2.5-11 : PRACK request (CRS-AS to UE#2) 



PRACK tel:+l-212-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP crsas.home2 .net;branch=z9hG4bK764Q32 .1, SIP/2. 0/UDP 

From: 

To: 

Call-ID: 

Cseq: 

Require: precondition, lOOrel, early-session 

RSeq: 9022 

Contact : <sip : crs-as .homel .net>; +g. 3gpp . icsi_ref="urn%3Aurn-7%3gpp- service . ims . icsi .mmtel" 

Content-Type: application/sdp 

Content -Disposition: early- session 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : eee : f f f : ccc : ddd 

s = - 

c = IN IP6 6666 : :eee:fff :aaa:bbb 

t=0 

m=video 34 RTP/AVP 98 

b=AS:75 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

m=audio 3456 RTP/AVP 97 

b=AS:2 5.4 

a=curr:qos local sendonly 

a=curr:qos remote none 

a=des:qos mandatory local sendonly 

a=des:qos mandatory remote recvonly 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; maxframes 



early SDP The early-session SDP offer (early SDP_0) contains a set of codecs supported to be used for CRS. The 
local preconditions are indicated as fulfilled. 

13-14 200 (OK) response (UE#2 to CRS-AS) see example in table A,2.5-13 

UE#2 sends the 200 (OK) response which contains an answer SDP for the PRACK request to CRS-AS. 
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Table A.2.5-13:200 (OK) response (UE#2 to CRS-AS) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 2 . visited2 .net ;branch=z9hG4bK361k21 . 1, SIP/2. 0/UDP 
scscf2.home2 .net ;branch=z9hG4bK764XC12 .1, SIP/2 .0/UDP 
scscf 1 .homel .net ;branch=z9hG4bK764z87 . 1 , SIP/2 . 0/UDP 
cr£5as.homel.net;branch=z9hG4bK7 64Q3 2 .1, SIP/2 .0/UDP 
scscf l.homel.net;branch=z9hG4bK3 3 2b2 3 .1, SIP/2 .0/UDP 
pcscf 1 . visitedl .net ;branch=z9hG4bK24 0f 34 . 1 , SIP/2 . 0/UDP 
[5555 : :aaa:bbb: ccc :ddd] : 13 5 7 ; comp=sigcomp ; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

Cseq: 128 PRACK 

Contact : 

Content-Type: application/sdp 

Content -Disposition: early- session 

Content-Length: (...) 

v=0 

o=- 2987933616 2987933616 IN IP6 5555 : : eee : f f f : aaa : bbb 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=video 3500 RTP/AVP 98 

b=AS:75 

a=curr:qos local recvonly 

a=curr:qos remote sendonly 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

m=audio 3466 RTP/AVP 97 

b=AS:2 5.4 

a=curr:qos local recvonly 

a=curr:qos remote sendonly 

a=des:qos mandatory local recvonly 

a=des:qos none remote sendonly 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; maxframes 



early SDP The early-session SDP answer (early SDP_A) contains a set of codecs supported by UE#2 to be used for 
CRS. The local preconditions are indicated as fulfilled. 

15-16 200 (OK) response (CRS-AS to UE#1) 

The CRS-AS forwards the 200 (OK) response which the answer SDP is deleted for the PRACK request. 

The CRS-AS instructs the MRF to send CRS media to UE#2. UE#2 presents the CRS media. 
17-18 200 (OK) response to INVITE request (UE#2 to CRS-AS) 

The called party answers the call. UE#2 sends a SIP 200 (OK) final response to the SIP INVITE request towards 

UE#1. 

19-20 ACK request (CRS-AS to UE#2) 

CRS-AS sends a SIP ACK request, which acknowledges the SIP 200 (OK) final response, to UE#2. 
21-22 re-INVITE request (CRS-AS to UE#2) see example in table A.2.5-21 
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Table A.2.5-21 : re-INVITE request (CRS-AS to UE#2) 



INVITE tel:+l-212-555-2222 SIP/2.0 

Via: 

From: 

To: 

Call-ID: 

Cseq: 128 INVITE 

Contact : <sip : crs-as .homel .net>; +g. 3gpp . icsi_ref="urn%3Aurn-7%3gpp- service . ims . icsi .mmtel" 

Content-Type: application/sdp 

Content-Disposition: session 

Content-Length: (...) 

v=0 

o=- 2987933617 2987933617 IN IP6 7777 : : eee : f f f : ccc : ddd 

s = - 

c=IN IP6 7777: :eee:fff :ccc:ddd 

t = 

m=video 34 RTP/AVP 98 

b=AS:75 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

m=audio 3456 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; maxframes 

a=rtpmap:96 telephone-event 



SDP: The SDP offer (SDP_0) contains a set of codecs to be used for original session received in the last SDP offer 
plus the continuous CRS media. If preconditions are used, the local preconditions are indicated as fulfilled. 

23-24 200 (OK) response to re-INVITE request (UE#2 to CRS-AS) see example in table A.2.5-23 
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Table A.2.5-23:200 (OK) response (UE#2 to CRS-AS) 



SIP/2.0 200 OK 

Via: 

From: 

To: 

Call-ID: 

Cseq: 

Contact : 

Content-Type: application/sdp 

Content-Disposition: session 

Content-Length: (...) 

v=0 

o=- 2987933617 2987933617 IN IP6 7777 : : eee : f f f : aaa : bbb 

s = - 

c = IN IP6 7777: :eee:fff :aaa:bbb 

t = 

m=video 3500 RTP/AVP 98 

b=AS:75 

a=curr:qos local recvonly 

a=curr:qos remote sendonly 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

m=audio 3456 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local sendrecv 

a=curr:qos remote sendrecv 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; maxframes=2 

a=rtpmap:96 telephone-event 



25-26 UPDATE request (CRS-AS to UE#1) see example in table A.2.5-25 

Table A.2.5-25:UPDATE request (CRS-AS to UE#1) 



UPDATE sip: user l_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6> SIP/2 . 

Via: 

From: 

To: 

Call-ID: 

Cseq: 

Contact : <sip : crs-as .homel .net>;+g. 3gpp . icsi_ref ="urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel" 

Content-Type: application/sdp 

Content-Disposition: session 

Content-Length: (...) 

v=0 

o=- 2987933618 2987933618 IN IP6 8888 :: eee : fff : ccc : ddd 

s = - 

c = IN IP6 8888 : :eee:fff :ccc:ddd 

t = 

m=audio 5678 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2 , 5, 7; maxframes 

a = r tpmap :96 telephone- event 



SDP: The SDP offer (SDP_0) contains a set of codecs to be used for regular session. If preconditions are used, the 
local preconditions are indicated as fulfilled. 

27-28 200 (OK) request to UPDATE request (UE#1 to CRS-AS) see example in table A.2.5-27 
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Table A.2.5-27:200 (OK) response (UE#1 to CRS-AS) 



SIP/2.0 200 OK 

Via: 

From: 

To: 

Call-ID: 

Cseq: 

Contact : 

Content-Type: application/sdp 

Content-Disposition: session 

Content-Length: (...) 

v=0 

o = - 2987933618 2987933618 IN IP6 8888 : : aaa : bbb : ccc : ddd 

s = - 

c=IN IP6 8888 :: aaa: bbb: ccc : ddd 

t=0 

m=audio 5678 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local sendrecv 

a=curr:qos remote sendrecv 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5, 7; maxframes=2 

a = r tpmap :96 telephone- event 



29-30 200 (OK) response to INVITE (CRS-AS to UE#1) 

The CRS-AS sends the SIP 200 (OK) response for the (initial) SIP INVITE request to UE#1. 

31-32 ACK request (UE#1 to CRS-AS) 

UE#1 sends a SIP ACK request, which acknowledges the SIP 200 (OK) final response, to CRS-AS. 

Upon receiving the SIP ACK request fi^om UE#1, AS shall instruct the MRF to mix CRS media and regular media 
during the conversation. 

33-34 ACK request (CRS-AS to UE#2) 

CRS-AS sends a SIP ACK request, which acknowledges the SIP 200 (OK) response of re-INVITE request, to 

UE#2. 
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Annex B (informative): 
Void 
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Annex C (normative): 

Registration for URN used within the current document 

Namespace ID: alert 

Registration Information: Registration version: I 

Registration date: TBD 

Declared registrant of the namespace: 

Registering organization: 3GPP 

Declaration of syntactic structure: 

The service-indication under the "service" alert-identifier for CRS service is "crs" and is used according to the 
ABNF as defined in draft-Iiess-dispatch-aIert-info-urns-00 [8]. 

Example: 

urn: alert: service : crs 

Relevant ancillary documentation: 3GPP TS 24. 183Community considerations: lANA 

Namespace considerations: There do not appear to be other URN namespaces that serve the same need of uniquely 
identifying 'alert' communication and information services. 

Identifier uniqueness considerations: This identifier is unique under the namespace of 'alert' URN. 

Identifier persistence considerations: This identifier is persistent, as long as it is registered with lANA. 

Conformance with URN syntax: The BNF in the 'Declaration of syntactic structure' in 
draft-liess-dispatch-alert-info-urns-00 [8] constrains the syntax for this URN scheme. 
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Annex D (informative): 

XML body in SIP message for indicating to UE 

D.1 CRS service indication XIVIL schema 
D.1.1 General 

This subclause defines XML schema and MIME type related to the CRS service indication feature. 

D.1.2 XIVIL schema 

<?xml version="l . 0" encoding="UTF-8" ?> 
<xs : schema 

xmlns :xs="http: //www.w3 . org/2 01/XMLSchema" 

elementFormDefault=" qualified" 

attributeFormDefault=" unqualified" > 

<xs:element name= ' f etchAlertInf o" type="crs"/> 
<xs : complexType name="crs"/> 
</xs : schema> 

D.1 .3 lANA registration template 

Editor"s note: The MIME type "application/vnd.3gpp.crs+xml" as defined in this subclause is to be registered in the 
lANA registry for Application Media Types based upon the following template. 

MIME media type name: 

application 

MIME subtype name: 

vnd.3gpp.crs+xml 

Required parameters: 

None 

Optional parameters: 

"charset" the parameter has identical semantics to the charset parameter of the "apphcation/xml" media type as specified 
in IETF RFC 3023 [21]. 

Encoding considerations: 

Same as encoding considerations of application/xml as specified in IETF RFC 3023 [21] 

Security considerations: 

Same as general security considerations for application/xml as specified in section 10 of IETF RFC 3023 [21]. In 
addition, this content type provides a format for exchanging information in SIP, so the security considerations from 
IETF RFC 3261 [19] apply. 

Interoperability considerations: 

Same as interoperability considerations as specified in section 3.1 of IETF RFC 3023 [21]. 

Published specification: 
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3GPP TS 24.183 " IP Multimedia Subsystem (IMS) Customized Ringing Signal", version 9.1.0, available via 
http://www.3gpp.org/specs/numbering.htm. 

Applications which use this media: 

Applications support the service continuity as described in the published specification. 

Intended usage: 

COMMON 

Additional information: 

1. Magic number(s): none 

2. File extension(s): none 

3. Macintosh file type code: none 

4. Object Identifiers: none 
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Annex E (normative): 

SDP a=content attribute "g.Sgpp.crs" value 

E.1 Introduction 

This annex provides the lANA registration information for a new value, g.3gpp.crs, for the SDP a=content media-level 
attribute defined in RFC 4976 [9]. The attribute value is used to indicate that an SDP media descriptions are associated 
with the CRS service. 

E.2 lANA registration 

SDN name: gjgpp.crs 

Description: Stream associated with the 3GPP Customized Ringing Signal (CRS) service. 

Reference: 3GPP TS 24.183 
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Annex F(informative): 
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